598383 - Utilities for Panorama tests

Status: RESOLVED FIXED

(Firefox Graveyard :: Panorama, defect, P3)

Description

[Ian Gilman [:iangilman]]

We've started to collect a few routines (such as creating an empty group, observing window close, etc) that we copy and paste from test to test. We should create a utilities JavaScript file to store them and load them from each test. I'm thinking: 

/browser/base/content/test/tabview/utils.js

Ehsan recommends using mozIJSSubscriptLoader:

https://developer.mozilla.org/en/mozIJSSubScriptLoader

Many tests already use it:

http://mxr.mozilla.org/mozilla-central/ident?i=mozIJSSubScriptLoader&tree=mozilla-central&filter=%2Ftest

Comment 1

[Michael Yoshitaka Erlewine [:mitcho]]

Great idea.

Comment 2

[Sean Dunn]

Some common tasks I'd like to see:
* Create group of size X,Y with N new tabs
* Create new window with N new tabs
* Synthesize mouse to reposition and resize item to new box over T seconds
* Synthesize platform-independent Panorama keyboard shortcut

I find one of the more frustrating aspects of writing tests is the proper teardown before calling finish(). One way to speed things up is to have each of the above routines pass back an optional function which would undo everything it created (and hide all the event processing).

The undo function would take one arg which is the next function to run after completion, since many teardown tasks require breaking out of the current processing frame and using the event system.

Responsibility would fall on the test writer not to prematurely delete these objects if they want to use the undo function.

Is there a more effective way to do ensure the original state before calling finish?

Comment 3

[Ian Gilman [:iangilman]]

Adding to b8; would be nice to get this started sooner rather than later so our tests can build on it.

This bug should be for getting utils.js started, with maybe just one routine (like creating a new group), and using it from at least one test. That way we can have the new structure in place and we can all start building on it. Additional features should be handled in followup bugs.

Comment 4

[Ian Gilman [:iangilman]]

Another possible technique would be to stick them in head.js. This actually sounds like it might be cleaner (less boilerplate needed per file). 

From https://developer.mozilla.org/en/Browser_chrome_tests : 

You can collect common utils and helpers in a file called head.js, that must live in the same folder as the browser-chrome tests. This file will be injected into the test scope for each test living in the same folder. Notice that any function call in head.js main scope will run before the main test() method.

Comment 5

[Ian Gilman [:iangilman]]

(In reply to comment #2)
> Is there a more effective way to do ensure the original state before calling
> finish?

Check out bug 603820.

Comment 6

[Raymond Lee [:raymondlee]]

Attachment: v1

Created one method in the head.js, and updated some tests.  Please file follow-up bugs for other methods.

Comment 7

[Raymond Lee [:raymondlee]]

Attachment: v1

Comment 8

[Ian Gilman [:iangilman]]

Comment on attachment 483920 [details] [diff] [review]
v1

Beautiful! Assigning to Dolske for review. Note that it won't need approval, as it's just a test change.

Sean, can you file follow-ups for your additional feature suggestions?

Comment 9

[Justin Dolske [:Dolske]]

Comment on attachment 483920 [details] [diff] [review]
v1

rs=me

Comment 10

[Raymond Lee [:raymondlee]]

Attachment: patch for check-in

r=dolske

Comment 11

[Ian Gilman [:iangilman]]

http://hg.mozilla.org/mozilla-central/rev/7c23a7a87029