Testing the Add-on SDK

Add-ons using the techniques described in this document are considered a legacy technology in Firefox. Don't use these techniques to develop new add-ons. Use WebExtensions instead. If you maintain an add-on which uses the techniques described here, consider migrating it to use WebExtensions.

From Firefox 53 onwards, no new legacy add-ons will be accepted on addons.mozilla.org (AMO).

From Firefox 57 onwards, WebExtensions will be the only supported extension type, and Firefox will not load other types.

Even before Firefox 57, changes coming up in the Firefox platform will break many legacy extensions. These changes include multiprocess Firefox (e10s), sandboxing, and multiple content processes. Legacy extensions that are affected by these changes should migrate to WebExtensions if they can. See the "Compatibility Milestones" document for more.

A wiki page containing resources, migration paths, office hours, and more, is available to help developers transition to the new technologies.

From Add-on SDK repository

With a checkout of the mozilla/addon-sdk repository (or a checkout of the m-c repo and cd into the addon-sdk/source directory) there are many means to run the addon-sdk tests.

With CFX

CFX tests use the deprecated sdk/loader/cuddlefish, which is being replaced by toolkit/loader.

With cfx (which is part of the addon-sdk repo), we can run the first test suite which was produced for the Add-on SDK. This includes:

cfx testcfx: a suite of python tests which test cfx itself (which is written in python). This suite basically tests cfx xpi's ability to produce the xpi files that we expect it to.
cfx testex --filter <addon_example_folder_name>: a suite of tests which run test code for some example add-ons. This suite builds the example code, then runs these example add-on's test code.
cfx testaddons --filter <addon_folder_name>: a suite of tests which run add-ons, which are themseleves tests. This suite builds add-ons which are tests (ie: their main.js script's merely run tests and close firefox when their tests are done), and runs them as cfx run would.
cfx testpkgs --filter <file_name>:<test_name>: a suite of tests which run sdk module unit tests. This suite builds the entire addon-sdk repo as an add-on, like cfx xpi would, then runs the add-on like cfx test would. The majority of the tests run here are module unit tests, but there are various other tests included here as well.

Note: You must remember to run source bin/activate in order to enable cfx first.

With JPM

JPM tests all use the new toolkit/loader.

With jpm (which is not part of the add-on sdk repo, and must be installed separately) things more difficult without the Gulp commands provided by the gulpscript.js file in the addon-sdk repo. With gulp installed, and after installing the addon-sdk's npm dependencies, we can run the latter three test suites mentioned for cfx with jpm using the following commands:

gulp test:examples --filter <addon_example_folder_name>
gulp test:addons --filter <addon_folder_name>
gulp test:modules --filter <file_name>:<test_name>

or run all of the tests with gulp test.

With Travis

If you merely make a pull request for the mozilla/addon-sdk then all of the jpm tests mentioned above will be run on Travis-CI automatically and you will see the pass/fail results with a link to the log in the github pull request. Only on a linux machine at the moment.

From Mozilla-Central repository

With a checkout of the mozilla-central source code, one can always cd addon-sdk/source and use any of the methods described above, but in addtion to that there are a couple of mach commands available, and ofcourse there is the try server if you have access to that.

With Mach

There are two commands:

./mach mochitest -f jetpack-addon <optional_addon_path>: This runs the test add-ons mentioned for cfx testaddons and gulp test:addons with the older sdk/loader/cuddlefish used with cfx.
./mach mochitest -f jetpack-package <optional_file_path>: This runs the module unit tests mentioned for cfx testpkgs and gulp test:modules but in this case with the newer toolkit/loader used with jpm.