Created attachment 373237 [details] Example for setupModule and a shared module 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.
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?
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
Last Resolved: 10 years ago
Resolution: --- → INVALID
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.