My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
CommandLineFlags  
Command line flags
Updated Jun 6, 2012 by corbinrs...@gmail.com

Help

$ java -jar JsTestDriver.jar --help
 --browser VAR             : The path to the browser executables, separated by ','. Arguments can be passed to the executables separated by ';'. '%s' will be replaced with the initial url. If '%s' is not included the url will be appended to the argument list.
 --browserTimeout VAR      : The ms before a browser is declared dead.
 --captureConsole          : Capture the console (if possible) from the browser
 --config VAL              : Loads the configuration file
 --dryRunFor VAR           : Outputs the number of tests that are going to be run as well as their names for a set of expressions or all to see all the tests
 --help                    : Help
 --port N                  : The port on which to start the JsTestDriver server
 --preloadFiles            : Preload the js files
 --requiredBrowsers VAR    : Browsers that all actions must be run on.
 --reset                   : Resets the runner
 --server VAL              : The server to which to send the command
 --serverHandlerPrefix VAL : Whether the handlers will be prefixed with jstd
 --testOutput VAL          : A directory to which serialize the results of the tests as XML
 --tests VAR               : Run the tests specified by the supplied regular expression. Use '#' to denote the separation between a testcase and a test.
 --verbose                 : Displays more information during a run
 --plugins VAL[,VAL]       : Comma separated list of paths to plugin jars.
 --config VAL              : Path to configuration file.
 --basePath VAL            : Override the base path in the configuration file. Defaults to the parent directory of the configuration file.
 --runnerMode VAL          : The configuration of the logging and frequency that the runner reports actions: DEBUG, DEBUG_NO_TRACE, DEBUG_OBSERVE, PROFILE, QUIET (default), INFO
 --serverHandlerPrefix     : Prefix for all jstd paths (to avoid conflict with proxy)

Server Options

--port

When starting up a server all you need to specify is the --port on which port number should the server be running. The same port number is than used to both capture the browsers as well as for the test runner to connect to.

Status

Once the server is running you can visit the server base URL with your browser to see that status of the servers. If you started the server on port 4224 than you can visit the status of the server by visiting http://localhost:4224. Here is a sample output of the server status.

Capture This Browser



Captured Browsers:



Id: 2

Name: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10

Version: 5.0 (Macintosh; en-US)

Operating System: MacIntel



Id: 1

Name: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/528.16 (KHTML, like Gecko)

Version/4.0 Safari/528.16

Version: 5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16

Operating System: MacIntel

Browser Capture

Visiting http://localhost:4224/capture will automatically capture the browser by the server. At this point the browser is available to be used for running tests.

The browser does not have to be on the same machine. This allows a server running on one platform to capture browsers from other platform giving the developer full access to all browsers/platform combinations.

--browser

If you wish to auto-capture a browser on startup you can specify a list of paths (separated by comma ',') to the browser on the command line using this option. This will automatically launch the browser and capture it. This is useful when setting up JsTestDriver in ContinuousBuild mode. Arguments can be passed to the executables separated by ';'. '%s' will be replaced with the capture url. If '%s' is not included the capture url will be appended to the argument list.

Test Runner Options

If --port option is not present than we are running in a test runner mode. This client is run by the developer to run the tests in automated fashion from the IDE.

--captureConsole

Many browsers have a console object which has logging methods for debugging. When this option is specified than we try to intercept the console log messages and display them on the test runner standard out. This allows the developer to see what is going on on a remote browsers console to aid in debugging. (FireFox does not allow overwriting of the console object.)

--config

By default the test runner reads the jsTestDriver.conf file in the current directory to get its configuration. This option allows you to override the location of the ConfigurationFile.

--reset

Asks the server to reload the browsers. Sometimes it is passible that slave gets into an inconsistent state. For example a test has overridden some global variable. Sending a reset signal should restore the slave to standard configuration.

--server

Specifies the location of the server to connect to for running the tests. By default we try to use the location form the ConfigurationFile, but this option allows the developer to override the configuration file.

--testOutput

For ContinuousBuild it is often necessary to publish the test results in a file for later processing. This option specifies which directory the tests results should be written to. The test results are written in XML JUnit format which should be compatible with most of the continuous build systems out there. There will be one XML file written per browser captured. The format should be compatible with most continuous build systems which understand JUnit XML format.

--tests

Specifies which tests should be run.

  • all special keyword to run all of the tests.
  • TestCaseName run all tests for that test case.
  • TestCaseName#testName run only the specified test, useful when debugging a single test. See DebuggingWithJsTestDriver.
  • Additionally, it accepts regular expressions for any part of the string. '#' is reserved, and unexpected results may happen when using # in a test name.

--verbose

Normally the test runner tries to run as many tests as passible before reporting status of the test to the user. This is done for performance reasons. But it i possible that a test can hang the runner in this case you have no idea which tests is causing the problem since nothing is displayed. This option makes the test runner verbose and as a result it reports on every test as it runs allowing you to pinpoint the failure.

Comment by benjamin...@gmail.com, Jun 18, 2010

I assume there's no option to auto-capture a browser in strict mode. Is it correct?

Comment by Spuds...@gmail.com, Jul 31, 2010

The documentation is out of sync with the code at the moment. The 1.2.2 version produces the following output:

$ java -jar c:/dev/jstestdriver/JsTestDriver-1.2.2.jar --help
 --browser VAR        : The path to the browser executable
 --browserTimeout VAR : The ms before a browser is declared dead.
 --captureConsole     : Capture the console (if possible) from the browser
 --config VAL         : Loads the configuration file
 --dryRunFor VAR      : Outputs the number of tests that are going to be run as
                        well as their names for a set of expressions or all to
                        see all the tests
 --help               : Help
 --port N             : The port on which to start the JsTestDriver server
 --preloadFiles       : Preload the js files
 --reset              : Resets the runner
 --server VAL         : The server to which to send the command
 --testOutput VAL     : A directory to which serialize the results of the tests
                        as XML
 --tests VAR          : Run the tests specified in the form testCase.testName
 --verbose            : Displays more information during a run
Comment by zachleat...@gmail.com, Aug 27, 2010

+1 to Benjamin's comment to allow strict mode and auto-capture.

Comment by daniel.n...@gmail.com, Oct 12, 2011

How can I stop the server from command line? I'm starting the server and running the tests from the command line, is there any way to stop the server, other than killing the java process?

Comment by bartw...@gmail.com, Nov 15, 2011

I want to only have a single test file per configuration file - different test files running in the isame configuration file can coomunicate with eachother which is a very bad thing with unit tests.

How can I run multiple configuration files at one time? I wish the '-- config' command line argument could accept wild cards to work with all the config files in a directory recursivley.

Running multiple config files is possible in the IntelliJ IDE.

Why can't I do it from the command line?

I need to integrate with Team City and this will be a pain in the butt. Putting all tests in a single config file is a bad practice with unit testing bacause tests are not isolated.

Comment by jer...@syapse.com, Mar 29, 2012

Bart W,

What would be the point of having multiple config files? The browser only has one context: loading two config files (worth of files) in to it wouldn't be any different from loading one file that has the contents of the other two. In other words, if you load suite A's files, then load suite B's, both will be in the browser's context, just as if you'd combined A and B in to AB and used AB as your config file.

If you just want to run test suite A, and then run test suite B, without their files ever co-mingling, just run jstestdriver twice, once with A's config file and once with B's.

Comment by brian.ew...@gmail.com, Apr 26, 2012

Undocumented:

Each browser in --browser can have arguments; these are supplied as a ';' separated list. The capture url will be passed as the last parameter to the browser UNLESS one of these arguments is '%s', in which case the argument will be passed in place of that argument. And on OS X, the browser is always run with 'open -a' in front of the command you told it to use. ie on windows/linux

java -jar JsTestDriver?.jar --browser browser1;arg1,browser2;%s;arg2 will launch: browser1 arg1 http://server:port/capture browser2 http://server:port/capture arg2

On OSX this will launch open -a browser1 arg1 http://server:port/capture open -a browser2 http://server:port/capture arg2 ... neither of which will work. You will need to do this: java -jar JsTestDriver?.jar --browser "browser1;%s;--args;arg1,browser2;%s;--args;arg2" which launches: open -a browser1 http://server:port/capture --args arg1 open -a browser2 http://server:port/capture --args arg2 ... thus passing arg1, arg2 to the browser.

The "--raiseOnFailure true" flag is also undocumented - this makes JsTestDriver? return a non-zero exit code on failure, which you'll need for integration into ant, maven etc.

Comment by ptr.ga...@gmail.com, May 22, 2012

Ok. Can anyone figure our how to use : --plugins VAL[,VAL] : Comma separated list of paths to plugin jars.

I'm trying to have coverage in my build system outside of projects. And I can't find any option (separate conf files or something) that can provide this functionality. I don't want to define plugin in my specific project configuration.

Comment by realjo...@gmail.com, Jun 19, 2012

what's DEBUG_OBSERVE for?

Comment by m.buettn...@gmail.com, Jul 7, 2013

It should be noted that --browserTimeout is a server option and has no effect if specified when running tests.

Comment by novater...@gmail.com, Jun 3, 2014

I have a suite of js-test-driver driven QUnit tests that unfortunately must interact with Quicktime and other plugins. I run using the --browsers switch, not the server. The plugin container may crash unpredictably causing a BrowserPanicException? and all subsequent tests to not run. Is there anyway to simply fail a test when this happens and relaunch the browser to continue running tests? If not this would be another use case for 1 config per test as mentioned above; however, that sounds highly inefficient.


Sign in to add a comment
Powered by Google Project Hosting