XPCShell tests ============== xpcshell tests are quick-to-run tests, that are generally used to write unit tests. They do not have access to the full browser chrome like ``browser chrome tests``, and so have much lower overhead. They are typical run by using ``./mach xpcshell-test`` which initiates a new ``xpcshell`` session with the xpcshell testing harness. Anything available to the XPCOM layer (through scriptable interfaces) can be tested with xpcshell. See ``Mozilla automated testing`` and ``pages tagged "automated testing"`` for more information. Introducing xpcshell testing ---------------------------- xpcshell test filenames must start with ``test_``. Creating a new test directory ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you need to create a new test directory, then follow the steps here. The test runner needs to know about the existence of the tests and how to configure them through the use of the ``xpcshell.ini`` manifest file. First add a ``XPCSHELL_TESTS_MANIFESTS += ['xpcshell.ini']`` declaration (with the correct relative ``xpcshell.ini`` path) to the ``moz.build`` file located in or above the directory. Then create an empty ``xpcshell.ini`` file to tell the build system about the individual tests, and provide any additional configuration options. Creating a new test in an existing directory ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If you're creating a new test in an existing directory, you can simply run: .. code:: brush: $ ./mach addtest path/to/test/test_example.js $ hg add path/to/test/test_example.js This will automatically create the test file and add it to ``xpcshell.ini``, the second line adds it to your commit. The test file contains an empty test which will give you an idea of how to write a test. There are plenty more examples throughout mozilla-central. Running tests ------------- To run the test, execute it by running the ``mach`` command from the root of the Gecko source code directory. :: # Run a single test: $ ./mach xpcshell-test path/to/tests/test_example.js # Test an entire test suite in a folder: $ ./mach xpcshell-test path/to/tests/ # Or run any type of test, including both xpcshell and browser chrome tests: $ ./mach test path/to/tests/test_example.js The test is executed by the testing harness. It will call in turn: - ``run_test`` (if it exists). - Any functions added with ``add_task`` or ``add_test`` in the order they were defined in the file. See also the notes below around ``add_task`` and ``add_test``. xpcshell Testing API -------------------- xpcshell tests have access to the following functions. They are defined in :searchfox:`testing/xpcshell/head.js ` and :searchfox:`testing/modules/Assert.sys.mjs `. Assertions ^^^^^^^^^^ - ``Assert.ok(truthyOrFalsy[, message])`` - ``Assert.equal(actual, expected[, message])`` - ``Assert.notEqual(actual, expected[, message])`` - ``Assert.deepEqual(actual, expected[, message])`` - ``Assert.notDeepEqual(actual, expected[, message])`` - ``Assert.strictEqual(actual, expected[, message])`` - ``Assert.notStrictEqual(actual, expected[, message])`` - ``Assert.rejects(actual, expected[, message])`` - ``Assert.greater(actual, expected[, message])`` - ``Assert.greaterOrEqual(actual, expected[, message])`` - ``Assert.less(actual, expected[, message])`` - ``Assert.lessOrEqual(actual, expected[, message])`` These assertion methods are provided by :searchfox:`testing/modules/Assert.sys.mjs `. It implements the `CommonJS Unit Testing specification version 1.1 `__, which provides a basic, standardized interface for performing in-code logical assertions with optional, customizable error reporting. It is *highly* recommended to use these assertion methods, instead of the ones mentioned below. You can on all these methods remove the ``Assert.`` from the beginning of the name, e.g. ``ok(true)`` rather than ``Assert.ok(true)``, however keeping the ``Assert.`` prefix may be seen as more descriptive and easier to spot where the tests are. ``Assert.throws(callback, expectedException[, message])`` ``Assert.throws(callback[, message])`` Asserts that the provided callback function throws an exception. The ``expectedException`` argument can be an ``Error`` instance, or a regular expression matching part of the error message (like in ``Assert.throws(() => a.b, /is not defined/``). ``Assert.rejects(promise, expectedException[, message])`` Asserts that the provided promise is rejected. Note: that this should be called prefixed with an ``await``. The ``expectedException`` argument can be an ``Error`` instance, or a regular expression matching part of the error message. Example: ``await Assert.rejects(myPromise, /bad response/);`` Test case registration and execution ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``add_task([condition, ]testFunc)`` Add an asynchronous function or to the list of tests that are to be run asynchronously. Whenever the function ``await``\ s a `Promise `__, the test runner waits until the promise is resolved or rejected before proceeding. Rejected promises are converted into exceptions, and resolved promises are converted into values. You can optionally specify a condition which causes the test function to be skipped; see `Adding conditions through the add_task or add_test function <#adding-conditions-through-the-add-task-or-add-test-function>`__ for details. For tests that use ``add_task()``, the ``run_test()`` function is optional, but if present, it 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. See `Async tests <#async-tests>`__, below, for more information. ``add_test([condition, ]testFunction)`` Add a test function to the list of tests that are to be run asynchronously. You can optionally specify a condition which causes the test function to be skipped; see `Adding conditions through the add_task or add_test function <#adding-conditions-through-the-add-task-or-add-test-function>`__ for details. Each test function must call ``run_next_test()`` when it's done. For tests that use ``add_test()``, ``the run_test()`` function is optional, but if present, it 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()``. See `Async tests <#async-tests>`__, below, for more information. ``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. See `Async tests <#async-tests>`__, below, for more information. **``registerCleanupFunction``**\ ``(callback)`` Executes the function ``callback`` after the current JS test file has finished running, regardless of whether the tests inside it pass or fail. You can use this to clean up anything that might otherwise cause problems between test runs. If ``callback`` returns a ``Promise``, the test will not finish until the promise is fulfilled or rejected (making the termination function asynchronous). Cleanup functions are called in reverse order of registration. ``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. 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:: **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). .. note:: **Note:** ``do_register_cleanup`` will perform any cleanup operation *before* the profile and the network is shut down by the observer notifications. ``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 by calling ``load('extra_helpers.js')``. Utility ^^^^^^^ ``do_parse_document(path, type)`` Parses and returns a DOM document. ``executeSoon(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.) Multiprocess communication ^^^^^^^^^^^^^^^^^^^^^^^^^^ ``do_send_remote_message(name, optionalData)`` Asynchronously send a message to all remote processes. Pairs with ``do_await_remote_message`` or equivalent ProcessMessageManager listeners. ``do_await_remote_message(name, optionalCallback)`` Returns a promise that is resolved when the message is received. Must be paired with\ ``do_send_remote_message`` or equivalent ProcessMessageManager calls. If **optionalCallback** is provided, the callback must call ``do_test_finished``. If optionalData is passed to ``do_send_remote_message`` then that data is the first argument to **optionalCallback** or the value to which the promise resolves. xpcshell.ini manifest --------------------- The manifest controls what tests are included in a test suite, and the configuration of the tests. It is loaded via the \`moz.build\` property configuration property. The following are all of the configuration options for a test suite as listed under the ``[DEFAULT]`` section of the manifest. ``tags`` Tests can be filtered by tags when running multiple tests. The command for mach is ``./mach xpcshell-test --tag TAGNAME`` ``head`` The relative path to the head JavaScript file, which is run once before a test suite is run. The variables declared in the root scope are available as globals in the test files. See `Test head and support files <#test-head-and-support-files>`__ for more information and usage. ``firefox-appdir`` Set this to "browser" if your tests need access to things in the browser/ directory (e.g. additional XPCOM services that live there) ``skip-if`` ``run-if`` ``fail-if`` For this entire test suite, run the tests only if they meet certain conditions. See `Adding conditions in the xpcshell.ini manifest <#adding-conditions-through-the-add-task-or-add-test-function>`__ for how to use these properties. ``support-files`` Make files available via the ``resource://test/[filename]`` path to the tests. The path can be relative to other directories, but it will be served only with the filename. See `Test head and support files <#test-head-and-support-files>`__ for more information and usage. ``[test_*]`` Test file names must start with ``test_`` and are listed in square brackets Creating a new xpcshell.ini file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When creating a new directory and new xpcshell.ini manifest file, the following must be added 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 └──tests/xpcshell └──xpcshell.ini # or feature ├──moz.build └──tests ├──moz.build └──xpcshell └──xpcshell.ini Test head and support files ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Typically in a test suite, similar setup code and dependencies will need to be loaded in across each test. This can be done through the test head, which is the file declared in the ``xpcshell.ini`` manifest file under the ``head`` property. The file itself is typically called ``head.js``. Any variable declared in the test head will be in the global scope of each test in that test suite. In addition to the test head, other support files can be declared in the ``xpcshell.ini`` manifest file. This is done through the ``support-files`` declaration. These files will be made available through the url ``resource://test`` plus the name of the file. These files can then be loaded in using the ``ChromeUtils.import`` function or other loaders. The support files can be located in other directory as well, and they will be made available by their filename. :: # File structure: path/to/tests ├──head.js ├──module.jsm ├──moz.build ├──test_example.js └──xpcshell.ini :: # xpcshell.ini [DEFAULT] head = head.js support-files = ./module.jsm ../../some/other/file.js [test_component_state.js] .. code:: brush: // head.js var globalValue = "A global value."; // Import support-files. const { foo } = ChromeUtils.import("resource://test/module.jsm"); const { bar } = ChromeUtils.import("resource://test/file.jsm"); .. code:: brush: // test_example.js function run_test() { equal(globalValue, "A global value.", "Declarations in head.js can be accessed"); } Additional testing considerations --------------------------------- Async tests ^^^^^^^^^^^ Asynchronous tests (that is, those whose success cannot be determined until after ``run_test`` finishes) can be written in a variety of ways. Task-based asynchronous tests ----------------------------- The easiest is using the ``add_task`` helper. ``add_task`` can take an asynchronous function as a parameter. ``add_task`` tests are run automatically if you don't have a ``run_test`` function. .. code:: brush: add_task(async function test_foo() { let foo = await makeFoo(); // makeFoo() returns a Promise equal(foo, expectedFoo, "Should have received the expected object"); }); add_task(async function test_bar() { let foo = await makeBar(); // makeBar() returns a Promise Assert.equal(bar, expectedBar, "Should have received the expected object"); }); Callback-based asynchronous tests ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You can also use ``add_test``, which takes a function and adds it to the list of asynchronously-run functions. Each function given to ``add_test`` must also call ``run_next_test`` at its end. You should normally use ``add_task`` instead of ``add_test``, but you may see ``add_test`` in existing tests. .. code:: brush: add_test(function test_foo() { makeFoo(function callback(foo) { // makeFoo invokes a callback once completed equal(foo, expectedFoo); run_next_test(); }); }); add_test(function test_bar() { makeBar(function callback(bar) { equal(bar, expectedBar); run_next_test(); }); }); Other tests ^^^^^^^^^^^ We can also 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. Newer tests prefer the use of ``add_task`` rather than this method. This can be achieved with ``do_test_pending()`` and ``do_test_finished()``: .. code:: brush: 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) { equal(result, expectedResult); // Close previous do_test_pending() call. do_test_finished(); }); } Testing in child processeses ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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: #. 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. #. 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. Use `AppConstants.jsm `__ for determining the platform, for example: .. code:: brush: ChromeUtils.import("resource://gre/modules/AppConstants.jsm"); let isMac = AppConstants.platform == "macosx"; Conditionally running a test ---------------------------- There are two different ways to conditional skip a test, either through Adding conditions through the ``add_task`` or ``add_test`` function ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You can use conditionals on individual test functions instead of entire files. The condition is provided as an optional first parameter passed into ``add_task()`` or ``add_test()``. The condition is an object which contains a function named ``skip_if()``, which is an `arrow function `__ returning a boolean value which is **``true``** if the test should be skipped. For example, you can provide a test which only runs on Mac OS X like this: :: ChromeUtils.import("resource://gre/modules/AppConstants.jsm"); add_task({ skip_if: () => AppConstants.platform != "mac" }, async function some_test() { // Test code goes here }); Since ``AppConstants.platform != "mac"`` is ``true`` only when testing on Mac OS X, the test will be skipped on all other platforms. .. note:: **Note:** Arrow functions are ideal here because if your condition compares constants, it will already have been evaluated before the test is even run, meaning your output will not be able to show the specifics of what the condition is. Adding conditions in the xpcshell.ini manifest ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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_example.js] skip-if = os == 'win' This example would skip running ``test_example.js`` on Windows. .. note:: **Note:** Starting with Gecko (Firefox 40 / Thunderbird 40 / SeaMonkey 2.37), you can use conditionals on individual test functions instead of on entire files. See `Adding conditions through the add_task or add_test function <#adding-conditions-through-the-add-task-or-add-test-function>`__ above for details. There are currently four 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_example.js] # bug xxxxxx fail-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_example.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 `__. Example: .. code:: bash $ ./mach xpcshell-test --jsdebugger browser/components/tests/unit/test_browserGlue_pingcentre.js 0:00.50 INFO Running tests sequentially. ... 0:00.68 INFO "" 0:00.68 INFO "*******************************************************************" 0:00.68 INFO "Waiting for the debugger to connect on port 6000" 0:00.68 INFO "" 0:00.68 INFO "To connect the debugger, open a Firefox instance, select 'Connect'" 0:00.68 INFO "from the Developer menu and specify the port as 6000" 0:00.68 INFO "*******************************************************************" 0:00.68 INFO "" 0:00.71 INFO "Still waiting for debugger to connect..." ... At this stage in a running Firefox instance: - Go to the three-bar menu, then select ``More tools`` -> ``Remote Debugging`` - A new tab is opened. In the Network Location box, enter ``localhost:6000`` and select ``Connect`` - You should then get a link to *``Main Process``*, click it and the Developer Tools debugger window will open. - It will be paused at the start of the test, so you can add breakpoints, or start running as appropriate. If you get a message such as: :: 0:00.62 ERROR Failed to initialize debugging: Error: resource://devtools appears to be inaccessible from the xpcshell environment. This can usually be resolved by adding: firefox-appdir = browser to the xpcshell.ini manifest. It is possible for this to alter test behevior by triggering additional browser code to run, so check test behavior after making this change. This is typically a test in core code. You can attempt to add that to the xpcshell.ini, however as it says, it might affect how the test runs and cause failures. Generally the firefox-appdir should only be left in xpcshell.ini for tests that are in the browser/ directory, or are Firefox-only. Running unit tests under a C++ debugger --------------------------------------- Via ``--debugger and -debugger-interactive`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You can specify flags when issuing the ``xpcshell-test`` command that will launch xpcshell in the specified debugger (implemented in `bug 382682 `__). Provide the full path to the debugger, or ensure that the named debugger is in your system PATH. Example: .. code:: eval $ ./mach xpcshell-test --debugger gdb --debugger-interactive netwerk/test/unit/test_resumable_channel.js # js>_execute_test(); ...failure or success messages are printed to the console... # js>quit(); On Windows with the VS debugger: .. code:: eval $ ./mach xpcshell-test --debugger devenv --debugger-interactive netwerk/test/test_resumable_channel.js Or with WinDBG: .. code:: eval $ ./mach xpcshell-test --debugger windbg --debugger-interactive netwerk/test/test_resumable_channel.js Or with modern WinDbg (WinDbg Preview as of April 2020): .. code:: eval $ ./mach xpcshell-test --debugger WinDbgX --debugger-interactive netwerk/test/test_resumable_channel.js Debugging xpcshell tests in a child process ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To debug the child process, where code is often being run in a project, set MOZ_DEBUG_CHILD_PROCESS=1 in your environment (or on the command line) and run the test. 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 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.)