PLEASE, Please, please be sure to understand that the
but it can be
in most any host application. Most of the bugs reported against the
issues. The most common mistake is to file a DOM or event handling issue,
such as trouble getting to a property of the
window object or
will eventually be reclassified into the correct component, getting
the component right from the start helps developers to swiftly fix the
Because the tests are not always run in the browser, it is important that you not refer to any objects that are part of the browser or DOM. For example, you must not refer to the following objects, or methods or properties of the following objects:
- form elements
If you would like to write tests that cover DOM objects, talk to the people at mozilla.dev.quality, or see the quality assurance group's page. You should also check out the NGLayout project's page on how you can help.
Which areas should I write tests for?
If you would like to contribute tests to the library, please contact the coordinator.
The tests that are currently available on mozilla.org are checked into
You must check them out explicitly as they are not part of the SeaMonkeyAll
partition. (Where the bulk of the Mozilla source code is.) If you already
have an existing source tree, getting the tests is a easy as:
cvs up -d tests
If you do not already have a Mozilla source tree, see the instructions on checking out source code for information on how to set up your CVSROOT and log in.
new test driver,
allows for a simpler test case layout, while still maintaining
with the previous driver. Both test drivers expect the tests to be laid
out in a directory structure that
is exactly three levels deep. Currently,
is the root of all tests. Under the root, you will find the
Test suite directories, such as
src directory contains Java classes used in the
LiveConnect tests, not actual test suites.) Each Test Suite has
a collection of Test Categories underneath it. Test cases are
placed in the Test Category directory, in a .js file.
To the jsDriver.pl, shell.js is a magic file. If it exists in either the Test Suite or the Test Category directory, it is loaded before the testcase executes. If it exists in both directories, the Test Suite version is loaded before the Test Category version. In this way, common functions can be shared among testcases.
The bulk of the tests follow the format described in the template.js file. It consists of a brief comment describing what the test is about, some variable initialization, and some test cases.
Newer testcases are even simpler, because they use the smaller shell.js. Look at the testcases in ecma_3/Exceptions/ for an example of how to write testcases under this shell.js
Each test case has three parts: a string representation of what you are testing, the expected result, and the actual result. You can write functions to generate the test cases, or you can hard-code all the test data. The structure of the test is up to you. Check out some of the existing tests for examples.
Testcases with filenames ending in -n, as in
catchguard-001-n.js, signify to the test driver that
they are expected to fail. That is, an exit code of 3 should be
considered success, anything else is a failure. (Normally exit code 0
implies success.) You can specify an arbitrary exit code as the success
code by outputting a line of the format
EXPECT EXIT: n
n is the code to expect. You can force your
testcase to exit with a specific exit code with the
man page for jsDriver.pl
for more information.
First, retrieve the
directory. You can download this from
or one of the
in a file called pub/js/js-tests-<date-stamp>.tar.gz,
or you can check it out directly from
If you have a complete Mozilla source tree, change to the
mozilla/jsdirectory, and issue the command
cvs up -d teststo retrieve the
testsdirectory from cvs.
- Second, read the man page for jsDriver.pl
- Third, make sure you have the Getopt::Mixed Perl module installed.
- Fourth, run jsDriver.pl as described in the man page.
- Finally, Submit your results to the test coordinator, the JS Engine newsgroup, or file bugs directly in Bugzilla.
- Test source
- JS Language References
- man page for jsDriver.pl
- Rhino homepage
- Spidermonkey homepage
Original page by Christine Begle of
Modified by Robert Ginda
Currently maintained by Bob Clary