Bugzilla – Full Text Bug Listing
| Summary: | Unit-test plugin no longer works | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Simon Kaegi <simon_kaegi> |
| Component: | Client | Assignee: | Simon Kaegi <simon_kaegi> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andrew.eisenberg, antonm, mamacdon, susan |
| Version: | 0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Simon Kaegi
(In reply to comment #0) > For 0.3 we should see if there is anything clever we can do in the short term > but barring a solution remove the unit test plugin from the defaults for now as > its broken. From what I could see, the unittest plugin itself works but the individual tests don't due to broken dependencies. Did you have something more clever in mind than changing all the relative paths in the test files to make them resolve? Removing from defaults.pref for 0.3. Moving to 0.5 but might continue to work on it in 0.4 but not expose it directly. *** Bug 371441 has been marked as a duplicate of this bug. *** I'm having a look at this now. I re-enabled the unittest plugin. I am able to run the tests properly if all the scripts as well as the baseUrl parameter of the require call are set to a fully qualified url. This is not a viable option in practice, but it does show that it is possible to get this working. More digging around: If the test file does not use an absolute url to grab dependencies, then this URL must be injected into the script somehow. It does seem that something like wirejs (https://github.com/cujojs/wire) would be appropriate here to handle the dependency injection. I am also going to look at running tests inside of a pure js file to see if we can get things a bit better. All right. I now have a way to run single .js files as unit tests. The js file needs to export a 'testcase' variable into global scope and this will be picked up by the test runner. I know that it is not standard to export the testcase as a global variable, so I'll see if I can also capture ther tests if it is exported as a requirejs module. *** Bug 372399 has been marked as a duplicate of this bug. *** Since it seems like there are lots of unit test-related bugs open that are all saying similar things, I'll try to consolidate a bit. Here's a comment that I just added to bug 372399, which I just closed as a duplicate of this one: 've done some work here and it is now possible (in my private branch) to run most Orion unit tests (either html or js) using a context menu. I say "most" because there are some caveats and assumptions I made to get this going. In general, there are two ways to reference a file in the workspace: through the workspace, using a url like this: http://orion.eclipse.org/file/c/bundles/org.eclipse.orion.client.core/web/js-tests/serviceRegistry/test.html Or through a site (if one is set up that includes the given directory) and it would look something like this: http://orion.eclipse.org/js-tests/serviceRegistry/test.html These two different URLs for referencing the same file has consequences for how the AMD modules get wired up and searched for. In general, if a module can be referenced using the same absolute URL in both situations (eg- dojo, or orion/plugin), then the wiring lookup should be absolute when running the tests. On the other hand, if a module can be referenced using the same relative url in both situations (eg- a module defined in ../) then wiring lookup should be relative when running the tests. It seems like for most situations inside of Orion itself, the wiring can be absolute, so in most situations, it will be possible to run using the context menu. The problem will happen when a single test module will mix relative and absolute references to required modules. I created a branch on the canonical repository called Bug361002-unittest-plugin. What I have now is useful and seems to work for the orion unit tests (except that in the html files, the baseUrl parameter must be changed from '../..' to '/' so that absolute urls are used to find modules instead of relative ones. This is not useful in all situations, but it is at least a reasonable thing to start with. I changed the command so that the "Run as unit test" only appears when the string [Tt]est appears in the file name and the extension is either .js or .html. Perhaps this is a good start and once we have the capability to run some unit tests through the navigator, we can start to think about a general wring mechanism for launching tests. Simon, would you be able to have a look at this when you get a chance? I'm asking you since you are already assigned to the bug. Thanks. Absolute URLs would work for own self-hosted tests but not as a general unit test solution so I'm not sure this is sufficient. In eclipse we run tests against a target platform and what I wonder is if we could layer something on top of the sites to do something similar. Nice analogy about a target platform. I see that it is more generally useful to open an html file (or other file) in the context of a given site. Perhaps there would be two commands, one for unit tests and one for run in site. There would be sub-commands in each for each site. It would also be nice to be able to run with parameters. I wouldn't want to have too many commands, so maybe run with parameters and run in site could be combined somehow. We need to update this to our new Mocha/Chai story This open bug report had a target milestone in the past. The target milestone has been removed. Please target for a date in the future or leave the target blank if it is not known. Is this still a problem, Simon? Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html |