jsDriver.pl
|
[-hkt] [-b BUGURL] [-c CLASSPATH] [-f OUTFILE]
[-j JAVAPATH] [-l TESTLIST ...] [-L NEGLIST ...] [-p TESTPATH]
[-s SHELLPATH] [-u LXRURL] [--help] [--confail] [--trace]
[--classpath=CLASSPATH] [--file=OUTFILE] [--javapath=JAVAPATH]
[--list=TESTLIST] [--neglist=TESTLIST] [--testpath=TESTPATH]
[--shellpath=SHELLPATH] [--lxrurl=LXRURL] {-e ENGINETYPE |
--engine=ENGINETYPE}
|
If a file named shell.js exists in either the Test Suite or the Test Category directory, it is loaded into the shell before the testcase. If shell.js exists in both directories, the version in the Test Suite directory is loaded first, giving the version associated with the Test Category the ability to override functions previously declared. You can use this to create functions and variables common to an entire suite or category.
Testcases can report failures back to jsDriver.pl in one of
two ways. The most common is to write a line of text containing
the word FAILED!
to STDOUT or STDERR.
When the engine encounters a matching line, the test is marked as
failed, and any line containing FAILED!
is displayed in
the failure report. The second way a test case can report failure is
to return an unexpected exit code. By default, jsDriver.pl
expects all test cases to return exit code 0, although a test
can output a line containing EXPECT EXIT n
where
n is the exit code the driver should expect to see. Testcases
can return a nonzero exit code by calling the shell function
quit(n)
where n
is the
code to exit with. The various JavaScript shells report
non-zero exit codes under the following conditions:
Reason | Exit Code |
---|---|
Engine initialization failure. | 1 |
Invalid argument on command line. | 2 |
Runtime error (uncaught exception) encountered. | 3 |
File argument specified on command line not found. | 4 |
Reserved for future use. | 5-9 |
BUGNUMBER n
to STDOUT or STDERR,
jsDriver.pl interprets n
as a bugnumber
in the BugZilla bug
tracking system. In the event that a testcase which has specified
a bugnumber fails, a hyperlink to the BugZilla database
will be included in the output by prefixing the bugnumber with the
URL specified here. By default, URL is assumed to be
"http://bugzilla.mozilla.org/show_bug.cgi?id=".
TYPE | Engine |
---|---|
lcopt | LiveConnect, optimized |
lcdebug | LiveConnect, debug |
rhino | Rhino compiled mode |
rhinoi | Rhino interpreted mode |
rhinoms | Rhino compiled mode for the Microsoft VM (jview) |
rhinomsi | Rhino interpreted mode for the Microsoft VM (jview) |
smopt | Spider-Monkey, optimized |
smdebug | Spider-Monkey, debug |
xpcshell | XPConnect shell |
results-<engine-type>-<date-stamp>.html
MOZILLA_FIVE_HOME
environment variable. There is no
default (as it is usually not needed) for the Rhino shell.
perl jsDriver.pl -e smdebug -L lc*
lc*
into lc2 lc3
. Under
a DOS shell, you must explicitly list the directories.)
perl jsDriver.pl -e rhino -L rhino-n.tests
Executes all tests EXCEPT those listed in the
rhino-n.tests
file.
perl -I/home/rginda/perl/lib/ jsDriver.pl -e lcopt -l lc2
lc3 -f lcresults.html -k
Executes ONLY the tests under the lc2
and lc3
directories against the LiveConnect shell. Results will be written to
the file lcresults.html
AND the console. The
-I
option tells perl to look for modules in the
/home/rginda/perl/lib
directory (in addition to the
usual places), useful if you do not have root access to install new
modules on the system.