641682 - Add the feature to set a root for the require path in the test

Status: RESOLVED WONTFIX

(Testing Graveyard :: Mozmill, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Right now we have the problem with our Mozmill tests that we always have to specify the whole relative path to each of the modules. That's a lot of duplicated code and makes it harder to maintain and write code. It would be nice if the test or any module can set a root path for the require call, i.e.:

require("../../../lib/addons");
require("../../../lib/tabview");


vs.

rootPath = "../../../";

require("lib/addons");
require("lib/tabview");

Comment 1

[Heather Arthur [:harth]]

(In reply to comment #0)
> Right now we have the problem with our Mozmill tests that we always have to
> specify the whole relative path to each of the modules. That's a lot of
> duplicated code and makes it harder to maintain and write code. It would be
> nice if the test or any module can set a root path for the require call, i.e.:
> 
> require("../../../lib/addons");
> require("../../../lib/tabview");
> 
> 
> vs.
> 
> rootPath = "../../../";
> 
> require("lib/addons");
> require("lib/tabview");

We switched to CommonJS so we would get away from the magic of SHARED_ROOT, etc. You can always:

root = "../../../";
 
require(root + "lib/addons");
require(root + "lib/tabview");

Recommending WONTFIX.

Comment 2

[Jeff Hammel]

regardless of whether this fix is taken or not, there should be a solution for adding top-level resources.  Right now, the mozmill-tests take library functions from http://hg.mozilla.org/qa/mozmill-tests/file/12ab3c6de98c/lib and almost never require any other module.  

In any case, I'm not really clear what the solution is right now, but it makes it impossible to move tests around with the clearer system.  I'm pretty sure we *don't* want to take this bug, as is, as having only one root path doesn't really help and :harth's solution is as good as any.  OTOH, it would be nice to be able to specify, not in the test but at the harness level, that you want such-and-such directory to be discoverable via import (whether via require or another helper function)

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

The approach for the harness level sounds great IMO. It would make our tests way cleaner. I don't think that we have to file a new bug for it but could simply reopen this one for further discussions and a possible implementation?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Reopening given the discussion with Jeff on IRC and the latest comments which imply that it could be kinda useful to specify such a root outside of the Mozmill tests to simplify the creation process.

Comment 5

[cmtalbert]

(In reply to Jeff Hammel [:jhammel] from comment #2)
> it would be nice to be able to specify, not in the test but at the harness
> level, that you want such-and-such directory to be discoverable via import
> (whether via require or another helper function)
I like this idea, and I think it makes a bit of sense.  I really don't want to re-implement the SHARED_ROOT business cause that was a huge headache and we removed it for that very reason (too much magic, way too difficult to move tests around with it set, and became useless boilerplate that had to be copied on every single test).

Comment 6

[Jeff Hammel]

(In reply to Clint Talbert ( :ctalbert ) from comment #5)
> (In reply to Jeff Hammel [:jhammel] from comment #2)
> > it would be nice to be able to specify, not in the test but at the harness
> > level, that you want such-and-such directory to be discoverable via import
> > (whether via require or another helper function)
> I like this idea, and I think it makes a bit of sense.  I really don't want
> to re-implement the SHARED_ROOT business cause that was a huge headache and
> we removed it for that very reason (too much magic, way too difficult to
> move tests around with it set, and became useless boilerplate that had to be
> copied on every single test).

Internally, I just want a way to add (prepend, or maybe add after the file's parent dir?) to the root paths here:

https://github.com/mozautomation/mozmill/blob/master/mozmill/mozmill/extension/resource/modules/frame.js#L119

This would allow arbitrary augmentation and overriding of root-level modules.  In this way, I could use (e.g.) the libs of mozmill-automation without coding their exact paths in my test.

Presumedly, there would be a list that could be passed to the MozMill constructor on the python side and a CLI (list) argument.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Only one question remains for me right now. How would we handle modules which are located in another folder? That's necessary at least for the add-ons tests in our mozmill-tests repository. I agree with Clint that I don't want to see a return of the SHARED_ROOT problem.

Comment 8

[Jeff Hammel]

The proposal in comment 6 should not change (at all) the way tests work currently.  If it does, we should not use it.

Imagine the line in the code read:

rootPaths: [ios.newFileURI(file.parent).spec, some_other_file_spec, "resource://mozmill/modules/"],

In this case, if you're importing a module, it will 

1. first look relative to the file's parent (directory)
2. then look relative to some_other_file_spec, the user supplied directory
3. then look in mozmill/modules

So nothing is lost, just an additional place is checked for.

Comment 9

[Jeff Hammel]

Not sure if this is really a good first bug.  Henrik, if you're willing to mentor, please reset the flag and add yourself as a mentor.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozmill will reach its end of life soon. We are currently working on getting
all the tests for Firefox ported to Marionette. For status updates please see
bug 1080766.