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.
Starting from Firefox 53, no new legacy add-ons will be accepted on addons.mozilla.org (AMO) for desktop Firefox and Firefox for Android.
Starting from Firefox 57, only extensions developed using WebExtensions APIs will be supported on Desktop Firefox and Firefox for Android.
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 use WebExtensions APIs if they can. See the "Compatibility Milestones" document for more information.
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
CFX tests use the deprecated
sdk/loader/cuddlefish, which is being replaced by
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
JPM tests all use the new
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
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.
There are two commands:
./mach mochitest -f jetpack-addon <optional_addon_path>: This runs the test add-ons mentioned for
gulp test:addonswith the older
./mach mochitest -f jetpack-package <optional_file_path>: This runs the module unit tests mentioned for
gulp test:modulesbut in this case with the newer
With Try Server