Closed
Bug 488780
Opened 15 years ago
Closed 15 years ago
setupModule not executed for included shared modules
Categories
(Testing Graveyard :: Mozmill, defect, P1)
Testing Graveyard
Mozmill
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: whimboo, Unassigned)
Details
Attachments
(1 file)
709 bytes,
application/force-download
|
Details |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090416 Shiretoko/3.5b4pre ID:20090416030924 and Mozmill trunk When you are using a shared module and want to prepare some stuff it should normally be done inside setupModule. This is not possible for a shared module. The setupModule function simply doesn't get called. See the attached test and sample shared module. IMO this is a blocker which prevents us from correctly implementing shared modules.
Reporter | ||
Updated•15 years ago
|
Priority: -- → P1
Comment 1•15 years ago
|
||
So, the intention of the dependencies isn't to be able to pull in shared objects for use in your module. Creating a "heirarchy" isn't the direct intention of the dependency system although it may be an unintended side effect. The reason I draw this distinction is because we decided _not_ to go with a module hierarchy approach to test dependencies (like windmill and nose do) and instead go with a test _metadata_ approach for better distributability down the line. When you run a test the dependency system is instructed to make sure that test files dependencies are *imported* by the collector. It doesn't insure that they are *run* before your test. Tests should depend on shared modules for necessary functionality, not for state that is created by previous test runs, those kinds of dependency chains will limit our ability to distribute tests efficiently and also encourages test authors to leave around product states created by their test instead of cleaning it up in a teardownModule. Does this makes sense?
Reporter | ||
Comment 2•15 years ago
|
||
Sure. After talking on IRC with Mikeal it's much clearer now. Further we got it to run. The collector still has to be run inside the function which uses methods from other modules. This makes this bug invalid.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Assignee | ||
Updated•8 years ago
|
Product: Testing → Testing Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•