Writing xpcshell-based unit tests

This article is in need of a technical review.

 

The xpcshell tool can be used to test certain kinds of functionality. Anything available to the XPCOM layer (through scriptable interfaces) can be tested with xpcshell. See Mozilla automated testing and pages tagged "automated testing" for pointers to more information.

Your first xpcshell-based test

Creating your first xpcshell-based test is easy. Create a file named test_first.js (unit test filenames must start with test_) with the following:

function run_test() {
  // do some complex action, check whether the action's results were what are expected here
  // this is just an example, so we assert that true == true
  do_check_true(true);
}

This doesn't really test anything, but it gives you an idea how you'd actually write a test. If you want to execute the test, you must first add it to the xpcshell.ini manifest. Add the test file to an existing set of tests (say, for example, netwerk/test/unit/, but you should put it near the code it tests). You then execute your test using mach:

$ ./mach xpcshell-test netwerk/test/
...failure or success messages are printed to the console...
Note:

Single tests may be run using mach like so:

$ ./mach xpcshell-test <path_to_test_file>

Adding to your test

The test is executed by the test harness by calling the run_test function defined in the file. Anything you want to test must be spawned from this function.

If you have a group of files in a directory and they all include some common code that needs to run before or after your tests, to set up resources for example, you can put one copy of that code in a common source file and add it to the head or tail section of the manifest.

Each of your test files needs to contain at least a "run_test()" function. If the "run_test()" function runs to completion without throwing an exception, the test succeeds. If the your test needs to wait for asynchronous callbacks, you can tell the test harness to not kill the test when your callback has finished (as opposed to when run_test() has finished) with do_test_pending and do_test_finished (see below). add_test and run_next_test provide a nice interface around that if you want to run several asynchronous tests in succession.

If you want to import a common module in your tests you can use resource://test to load it. This special address always resolves to the current test folder.

Components.utils.import("resource://test/module.jsm"); // Import module.jsm that is in the same folder as current test.

XPCShell test functions

xpcshell tests have access to the following functions. They are defined in testing/xpcshell/head.js and testing/modules/Assert.jsm if you want to see how they work.

Test case registration and execution

add_test(testFunction)
Add a test function to the list of tests that are to be run asynchronously. Each test function must call run_next_test() when it's done. run_test() should also call run_next_test() to start execution of all asynchronous test functions. In most cases, you should rather use the more readable variant add_task.
run_next_test()
Run the next test function from the list of asynchronous tests. Each test function must call run_next_test() when it's done. run_test() should also call run_next_test() to start execution of all asynchronous test functions.
add_task(testGenerator)
Add a generator to the list of tests that are to be run asynchronously. Whenever the generator yields a Promise, the test runner waits until the promise is resolved or rejected before proceeding. As in Task.jsm, rejected promises are converted into exceptions, and resolved promises are converted into values. run_test() should also call run_next_test() to start execution of all asynchronous test functions. The test cases must not call run_next_test(), it is called automatically when the task finishes.
do_register_cleanup(callback)
Executes the function callback after the test has finished running, regardless of whether the test passes or fails. You can use this to clean up anything that might otherwise cause problems between test runs.
do_test_pending()
Delay exit of the test until do_test_finished() is called. do_test_pending() may be called multiple times, and do_test_finished() must be paired with each before the unit test will exit.
do_test_finished()
Call this function to inform the test framework that an asynchronous operation has completed. If all asynchronous operations have completed (i.e., every do_test_pending() has been matched with a do_test_finished() in execution), then the unit test will exit.

Assertions and logging

do_check_eq(a, b)
Call this function to assert that two objects are equal (using ==). If not equal, an exception is logged and the test case is halted.
do_check_neq(a, b)
Call this function to assert that two objects are not equal (using !=). If equal, an exception is logged and the test case is halted.
do_check_true(expr)
Call this function to assert that expr is equal to true.
do_check_false(expr)
Call this function to assert that expr is equal to false.
do_check_null(expr)
Call this function to assert that expr is equal to null.
do_print(messageText)
Call this function to print text to the test's log file.
do_throw(messageText)
Call this function to report an error and exit the test. The argument is a string that will be reported in the test's log file.
Note: While do_throw can be caught by a try/catch block, executing it will cause the test to fail when it completes.
Assert.throws(callback, expectedException)
Asserts that the provided callback function throws an exception. The expectedException argument can be a message string, an Error instance, or a regular expression matching part of the error message (like in Assert.throws(() => a.b, /is not defined/).

Environment

do_get_file(testdirRelativePath, allowNonexistent)
Returns an nsILocalFile object representing the given file (or directory) in the test directory. For example, if your test is unit/test_something.js, and you need to access unit/data/somefile, you would call do_get_file('data/somefile'). The given path must be delimited with forward slashes. You can use this to access test-specific auxiliary files if your test requires access to external files. Note that you can also use this function to get directories.
Note: If your test needs access to one or more files that aren't in the test directory, you should install those files to the test directory in the Makefile where you specify XPCSHELL_TESTS. For an example, see netwerk/test/Makefile.in#117.
do_get_profile()
Registers a directory with the profile service and returns an nsILocalFile object representing that directory. It also makes sure that the profile-change-net-teardown, profile-change-teardown, and profile-before-change observer notifications are sent before the test finishes. This is useful if the components loaded in the test observe them to do cleanup on shutdown (e.g., places).
do_get_idle()
By default XPCShell tests will disable the idle service, so that idle time will always be reported as 0. Calling this function will re-enable the service and return a handle to it; the idle time will then be correctly requested to the underlying OS. The idle-daily notification could be fired when requesting idle service. It is suggested to always get the service through this method if the test has to use idle.
do_get_cwd()
Returns an nsILocalFile object representing the test directory. This is the directory containing the test file when it is currently being run. Your test can write to this directory as well as read any files located alongside your test. Your test should be careful to ensure that it will not fail if a file it intends to write already exists, however.
load(testdirRelativePath)
Imports the JavaScript file referenced by testdirRelativePath into the global script context, executing the code inside it. The file specified is a file within the test directory. For example, if your test is unit/test_something.js and you have another file unit/extra_helpers.js, you can load the second file from the first simply by calling load('extra_helpers.js').
do_load_module(testdirRelativePath)
Calls do_get_file(testdirRelativePath), then registers the returned file.

Utility

do_parse_document(path, type)
Parses and returns a DOM document.
do_execute_soon(callback)
Executes the function callback on a later pass through the event loop. Use this when you want some code to execute after the current function has finished executing, but you don't care about a specific time delay. This function will automatically insert a do_test_pending / do_test_finished pair for you.
do_timeout(delay, fun)
Call this function to schedule a timeout. The given function will be called with no arguments provided after the specified delay (in milliseconds). Note that you must call do_test_pending so that the test isn't completed before your timer fires, and you must call do_test_finished when the actions you perform in the timeout complete, if you have no other functionality to test. (Note: the function argument used to be a string argument to be passed to eval, and some older branches support only a string argument or support both string and function.)

Async tests

When testing async APIs, we need to tell the test harness not to kill the test process once run_test() is finished, but to keep spinning the event loop until our callbacks have been called and our test has completed. This can be achieved with do_test_pending() and do_test_finished():

function run_test() {
  // Tell the harness to keep spinning the event loop at least
  // until the next do_test_finished() call.
  do_test_pending();

  someAsyncProcess(function callback(result) {
    do_check_eq(result, expectedResult);

    // Close previous do_test_pending() call.
    do_test_finished();
  });
}

Task-based asynchronous tests

If you have many such tests to perform, it's often easier to turn them into tasks, register them with add_task(), and invoke them with run_next_test():

function run_test() {
  run_next_test();
}

add_task(function test_foo() {
  let foo = yield makeFoo(); // makeFoo() returns a Promise<foo>
  do_check_eq(foo, expectedFoo);
});

add_task(function test_bar() {
  let foo = yield makeBar(); // makeBar() returns a Promise<bar>
  do_check_eq(bar, expectedBar);
});

Callback-based asynchronous tests

Alternatively, you may put them in separate functions, register them with add_test(), and invoke them with run_next_test():

function run_test() {
  run_next_test();
}

add_test(function test_foo() {
  makeFoo(function callback(foo) { // makeFoo invokes a callback<foo> once completed
    do_check_eq(foo, expectedFoo);
    run_next_test();
  });
});

add_test(function test_bar() {
  makeBar(function callback(bar) {
    do_check_eq(bar, expectedBar);
    run_next_test();
  });
});

Testing under Electrolysis

Since not all platforms support multi-process (electrolysis, aka "e10s"), you need to put any e10s-specific tests in a separate directory, and only run them if MOZ_IPC is defined. See /netwerk/test/Makefile.in for an example. Note that any "head_" or "tail_" scripts you have in your usual tests directory will not be run automatically in the new directory (but you can write a simple wrapper to load them: see "head_channels_clone.js" in netwerk/test/unit_ipc).

By default xpcshell tests run in the parent process. If you wish to run test logic in the child, you have several ways to do it:

  1. Create a regular test_foo.js test, and then write a wrapper test_foo_wrap.js file that uses the run_test_in_child() function to run an entire script file in the child. This is an easy way to arrange for a test to be run twice, once in chrome and then later (via the _wrap.js file) in content. See /network/test/unit_ipc for examples. The run_test_in_child() function takes a callback, so you should be able to call it multiple times with different files, if that's useful.
  2. For tests that need to run logic in both the parent + child processes during a single test run, you may use the poorly documented SendCommand() function, which takes a code string to be executed on the child, and a callback function to be run on the parent when it has completed. You will want to first call do_load_child_test_harness() to set up a reasonable test environment on the child. SendCommand returns immediately, so you will generally want to use do_test_pending/do_test_finished with it. NOTE: this method of test has not been used much, and your level of pain may be significant. Consider option #1 if possible.

See the documentation for run_test_in_child() and do_load_child_test_harness() in testing/xpcshell/head.js for more information.

Platform-specific tests

Sometimes you might want a test to know what platform it's running on (to test platform-specific features, or allow different behaviors). Unit tests are not normally invoked from a Makefile (unlike Mochitests), or preprocessed (so not #ifdefs), so platform detection with those methods isn't trivial.

Runtime detection

Some tests will want to only execute certain portions on specific platforms. One approach that's been used is to look for the existence of platform-specific components or interfaces. It's a bit hackish, but it's simple and it works.

  • For Windows:

var isWindows = ("@mozilla.org/windows-registry-key;1" in Components.classes);

  • For OS X:

var isOSX = ("nsILocalFileMac" in Components.interfaces);

  • For Linux:

var isLinux = ("@mozilla.org/gnome-gconf-service;1" in Components.classes);

Adding your tests to the xpcshell manifest

To add a test to an xpcshell manifest file, you simply put the test file name in square brackets [] on its own line in the file, like so:

#edit netwerk/test/unit/xpcshell.ini
[DEFAULT]
head = head_channels.js
tail =

[test_first.js]

If this is a new directory that doesn't have an xpcshell manifest file, create a new file named xpcshell.ini and then add the following to a moz.build file near that file in the directory hierarchy:

XPCSHELL_TESTS_MANIFESTS += ['path/to/xpcshell.ini']

Typically, the moz.build containing XPCSHELL_TESTS_MANIFESTS is not in the same directory as xpcshell.ini, but rather in a parent directory. Common directory structures look like:

  • feature/moz.build
  • feature/tests/xpcshell/xpcshell.ini

or

  • feature/moz.build
  • feature/tests/moz.build
  • feature/tests/xpcshell/xpcshell.ini

Adding conditions to a test

Sometimes you may want to add conditions to specify that a test should be skipped in certain configurations, or that a test is known to fail on certain platforms. You can do this in xpcshell manifests by adding annotations below the test file entry in the manifest, for example:

[test_first.js]
skip-if = os == 'win'

This example would skip running test_first.js on Windows. There are currently three conditionals you can specify:

skip-if

skip-if tells the harness to skip running this test if the condition evaluates to true. You should use this only if the test has no meaning on a certain platform, or causes undue problems like hanging the test suite for a long time.

run-if

run-if tells the harness to only run this test if the condition evaluates to true. It functions as the inverse of skip-if.

fail-if

fail-if tells the harness that this test is expected to fail if the condition is true. If you add this to a test, make sure you file a bug on the failure and include the bug number in a comment in the manifest, like:

[test_first.js]
# bug xxxxxx
fails-if = os == 'linux'
run-sequentially

run-sequentially basically tells the harness to run the respective test in isolation. This is required for tests that are not "thread-safe". You should do all you can to avoid using this option, since this will kill performance. However, we understand that there are some cases where this is imperative, so we made this option available. If you add this to a test, make sure you specify a reason and possibly even a bug number, like:

[test_first.js]
run-sequentially = Has to launch Firefox binary, bug 123456.
Manifest conditional expressions

For a more detailed description of the syntax of the conditional expressions, as well as what variables are available, see this page.

Running unit tests

Tests should be run using ./mach xpcshell-test path/to/tests/. To run a single test, use ./mach xpcshell-test path/to/test.js.

Running unit tests under a C++ debugger

Via --debugger and -debugger-interactive

You can specify flags when issuing the xpcshell-test command that will cause your test to stop right before running so you can attach to xpcshell in a debugger (implemented in bug 382682).

Example:

$ ./mach xpcshell-test --debugger gdb --debugger-interactive netwerk/test/test_resumable_channel.js
# js>_execute_test();
...failure or success messages are printed to the console...
# js>quit();

Debugging Electrolysis (e10s) xpcshell tests

Under e10s you have two processes. You can debug the chrome process, the child process, or both at the same time.

To debug the chrome process

simply use the --debugger-interactive and --debugger flags as described above.

To debug the child process

The child process is where your xpcshell test's JS code is being run, so it is often--but not always--the process you're interested in. To debug the child, set MOZ_DEBUG_CHILD_PROCESS=1 in your environment (or on the command line) and run the test, and you will see the child process emit a printf with its process ID, then sleep. Attach a debugger to the child's pid, and when it wakes up you can debug it:

$ MOZ_DEBUG_CHILD_PROCESS=1 ./mach xpcshell-test test_simple_wrap.js
CHILDCHILDCHILDCHILD
  debug me @13476

To debug both parent and child processes

Use MOZ_DEBUG_CHILD_PROCESS=1 to attach debuggers to each process. (For gdb at least, this means running separate copies of gdb, one for each process.)

Common problems

Events are not processed during test execution if not explicitly triggered. This sometimes causes issues during shutdown, when code is run that expects previously created events to have been already processed. In such cases, this code at the end of a test can help:

let thread = gThreadManager.currentThread;
while (thread.hasPendingEvents())
  thread.processNextEvent(true);