Jump to: navigation, search

Orion/Running the tests

Client tests

Orion's client tests are written in JavaScript using the mocha test framework. Assertions are provided by chai. The tests run in a web browser. This section explains how Orion developers should write unit tests.

Organizing tests

  • Every source bundle in the Orion client repo (that is, every child folder of bundles/) should have exactly 1 test page. This makes it easy for developers to run all the bundle's tests in one shot.
  • Tests should be divided into files organized by functional components. Each component gets a separate file.
    • For example, the JavaScript bundle has separate test files dealing with JS content assist, JS validation, JS parsing, etc.
  • All the test artifacts for a bundle should go under the {bundle}/web/js-tests/ folder.

Running tests

  • All the test pages in the product are listed in this file.
  • To run the tests for a bundle, simply load its test page file in a web browser.
    • For example, the test page for the Web Tools bundle is webtoolsMochaTests.html. Therefore, to run the tests for the Web Tools bundle, you would navigate to http://[some_orion_server]/js-tests/webtools/webtoolsMochaTests.html.

Running the Tests Locally for Sauce

If you want to run the tests on your local machine and have them talk to sauce labs, you will need to do the following:

  • Make sure you have an active sauce labs account
  • Make sure you have nodejs installed
  • Make sure you have grunt-cli installed. If not, run npm install -g grunt-cli
  • Using the information found in your Sauce labs users settings, set the two environment variables (in your console)
  • At this point you can either use the handy script for running the tests, or manually run them:
    • change to the directory where the tests are located
    • run npm install to bring in all the dependencies for the tests
    • run grunt

Writing tests

First read Mocha: Getting Started for the basics of how tests are structured.

To create a test file for a component, start with this skeleton and add more tests as necessary:

 1 // js-tests/foo/myNewTestFile.js
 2 define([
 3     "chai/chai",
 4     "mocha/mocha",
 5 ], function(chai) {
 6     var assert = chai.assert;
 8     describe("component X", function() {
 9         it("should do Y", function() {
10             assert.equal(1, 1, "Hopefully 1 == 1");
11         });
12         it("should do Z", function() {
13             // Make more assertions here
14         });
15     });
16 });

When you have a lot of tests, use nested describe()s to create a logical hierarchy among them.

Promises in tests

If your component performs asynchronous operations using promises, you may find it convenient to return a promise from the it() function, and use the promise's resolve() to pass or reject() to fail the test. This offers a cleaner alternative to mocha's done() callback when several async steps are involved. If your test rejects, it should provide an instance of Error as the value. Never call reject(null) or reject(undefined), or Mocha will count it as a pass!

 1 // js-tests/foo/myNewTestFile.js
 2 define([
 3     "chai/chai",
 4     "orion/Deferred",
 5     "mocha/mocha",
 6 ], function(chai, Deferred) {
 7     it("should do Y asynchronously with a promise", function() {
 8         var deferred = new Deferred();
 9         setTimeout(function() {
10             deferred.reject(new Error("This test should fail"));
11         }, 0);
12         return deferred;
13     });
14 });

Adding to the bundle's test page

After creating a new test file, you must add it to the parent bundle's test page. To do this, simply edit the test page and add a dependency in the require([ .. ]) that goes around the mocha.run() call:

 1 require(['mocha/sauce'], function(mocha) {
 2     mocha.setup('bdd');
 3     require([
 4         'js-tests/javascript/astManagerTests',
 5         'js-tests/javascript/contentAssistTests',
 6         'js-tests/javascript/finderTests',
 7         'js-tests/javascript/occurrencesTests',
 8         'js-tests/foo/myNewTestFile',
 9     ], function(){
10         mocha.run();
11     });
12 });

Reload the test page in a web browser, and your tests will be executed!

Writing a new bundle's test page

If you find yourself creating an entirely new bundle, then you'll have to create a test page for it. Start with this skeleton, and change as needed (pay close attention to the relative paths, in particular).

 1 <!DOCTYPE html>
 2 <html>
 3 <head>
 4     <title>My New Bundle Tests</title>
 5     <link rel="stylesheet" href="../../mocha/mocha.css" />
 6     <script src="../../requirejs/require.js"></script>
 7     <script>
 8         /*jslint amd:true*/
 9         require({
10             baseUrl: "../../"
11         });
12         require(["mocha/sauce"], function(mochaSauce) {
13             mochaSauce.setup("bdd");
14             require([
15                 /* List this bundle's test files here as dependencies */
16             ], function(){
17                 mochaSauce.run();
18             });
19         });
20     </script>
21 </head>
22 <body>
23     <h3>My New Bundle Tests</h3>
24     <div id="mocha"></div>
25 </body>
26 </html>

Note that we use the exports of mocha/sauce instead of the regular mocha global: this is necessary for build-time test integration. See Integrating tests with the build for more details.

Integrating tests with the build

To run a bundle's tests in the Orion nightly build, you must perform the following steps:

  1. Important! Ensure that the bundle's test page loads the Sauce-enabled version of mocha defined in sauce.js. Do not use the typical mocha global window.mocha.
    • To verify this, load the test page in a browser. You should see some XML looking like <testcase name="whatever"… printed to the developer console: this means your test is correctly Sauce-enabled. If you don't see a pile of XML, then your test page is wrong and will break the build.
  2. Open the package.json file and add your test page's URL to the urls array.
  3. After the next build, your test results should appear on the orion-client page on Hudson.

For details about the build-time unit test architecture, see Releng Builds.

Node.js Server Tests

Our Node server unit tests are written against the Mocha test framework, and run under Node.js. Developers are expected to run these tests before releasing changes to the server, and before publishing the minified orion package to npm.

Running the tests

From the org.eclipse.orion.client/modules/orionode directory, just run the command:

 npm test

This will invoke Mocha and produce console output showing which tests passed and failed.

If you want to pass custom arguments to Mocha, you'll need to invoke it explicitly like this:

 ./node_modules/mocha/bin/mocha [debug] [options] [files]

To make this easier, you can install Mocha as a global npm package (npm install mocha -g), and then invoke it as simply mocha from a command shell.

Writing more tests

When you're prototyping a new feature, writing unit tests for it is always a good idea. Here's how to write a test:

  1. Create a new file my_tests.js in the org.eclipse.orion.client/modules/orionode/test/ directory.
  2. Write your tests in the file. Here are two resources to help you get started:
  3. Run the tests.
    • You don't have to register your new tests with the framework; it will discover anything in the test/ directory automatically.

Helper data or classes should go in test/support/.

JVM Server tests

Setting up

  1. Set up your Eclipse IDE as explained in Orion/Getting the source.
  2. Make sure you have imported the test projects into your workspace, and they're open:
    • org.eclipse.orion.server.tests
    • org.eclipse.orion.server.tests.feature
  3. The test projects have additional dependencies over the rest of the Orion source code. The next 3 steps explain how to satisfy them.
  4. Add the plugins from your Eclipse SDK to your target platform:
    1. Go to Preferences > Target Platform, select your target definition and click Edit.
    2. Click Add... > Installation, then type ${eclipse_home} in the Location field.
    3. Click Finish.
    4. Now there should be 2 locations shown in your target definition. Click Finish.
  5. Now we will checkout the remaining test dependencies from CVS. Download this file:
  6. In your Eclipse IDE, go to File -> Import -> Team -> Team Project Set, select OrionServerTestDependencies.psf, and click Finish.
  7. At this point you should have no Java compilation errors. You can now run the tests.

Manually checking out the dependent projects

If the previous section fails for some reason, here's the list of projects from the .psf file. You can check them out manually if need be.

Projects from the Eclipse Platform CVS repository (/cvsroot/eclipse):

  • org.eclipse.core.runtime.compatibility
  • org.eclipse.core.runtime.compatibility.auth
  • org.eclipse.core.tests.harness
  • org.eclipse.core.tests.resources
  • org.eclipse.test.performance
  • org.eclipse.test.performance.data
  • org.eclipse.test.performance.win32

Projects from the Orbit CVS repository (/cvsroot/tools):

  • javax.mail.glassfish (Branch v1_4_1)
  • org.antlr.runtime (Branch v3_2_0)
  • org.hamcrest.core (Branch v1_1)
  • org.junit (Branch v3_8_2)
  • org.junit4 (Branch v4_8_2)


  1. Go to the org.eclipse.orion.server.tests project.
  2. Open the launchConfigurations folder, right-click All Server Tests.launch and choose Run As > All Server Tests.
  3. The JUnit view will open and display the test results.

To run just a subset of the tests, edit the launch configuration (Run > Run Configurations).