Closed Bug 598383 Opened 14 years ago Closed 14 years ago

Utilities for Panorama tests

Categories

(Firefox Graveyard :: Panorama, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: iangilman, Assigned: raymondlee)

References

Details

(Whiteboard: [qa-])

Attachments

(1 file, 2 obsolete files)

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
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?
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.
Blocks: 590793
Blocks: 597043
No longer blocks: 590793
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.
(In reply to comment #2) > Is there a more effective way to do ensure the original state before calling > finish? Check out bug 603820.
Status: NEW → ASSIGNED
Attached patch v1 (obsolete) — Splinter Review
Created one method in the head.js, and updated some tests. Please file follow-up bugs for other methods.
Attachment #483918 - Flags: feedback?(ian)
Attached patch v1 (obsolete) — Splinter Review
Attachment #483918 - Attachment is obsolete: true
Attachment #483920 - Flags: feedback?(ian)
Attachment #483918 - Flags: feedback?(ian)
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?
Attachment #483920 - Flags: review?(dolske)
Attachment #483920 - Flags: feedback?(ian)
Attachment #483920 - Flags: feedback+
Attachment #483920 - Flags: review?(dolske) → review+
r=dolske
Attachment #483920 - Attachment is obsolete: true
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Whiteboard: [qa-]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: