[ GettingStarted | TestCase | Config File | Flags | ContinuousBuild | Debugging | DesignPrinciples | Eclipse Plugin | Compatibility ]

The goal of JsTestDriver is to build a JavaScript test runner which:

1. easily integrates with continuous builds systems and
2. allows running tests on multiple browsers quickly to ease TDD style development.

Features

• Command Line Control: JavaScript code in the browser by design is not allowed to interact with the filesystem or command line. This creates problem when trying to run tests in an automated fashion. A good test runner needs to allow control from the command line so that tests can be launched from an automation script. This also implies that the tests need to be able to publish their results to standard out or a file, outside of the browser sandbox. The JavaScript takes care of controlling and marshaling test results from the browser sandbox and make them available on the command line interface (or Java API).
• Parallel Test Executions Across Browsers: JavaScript development means write once and test everywhere. It is quite common when developing that code passes in one browser but fails on others. If the developer is testing with just one browser then the most likely outcome is that the code works only in that browser. Checking the code into a continuous build than runs the code in all browsers and results in failure which are hard to debug, since the check-in can be quite large. JsTestDriver allows you to run your tests in parallel on many browsers and platforms at once. This is possible because the JsTestDriver server can capture any number of local or remote browsers.
• Fast Tests Execution: TDD development asks to run tests often. Many JavaScript tests runners require you to write an HTML wrapper file which you refresh to re-run the tests, as a result you end up with lots of HTML wrappers which are equivalent to test suites. This means that you can only run one tests suite on one browser at a time. It also means that the browser has to continually re-parse the production code as it executes the individual tests suites. Finally running individual tests is often not possible if the only control is browser refresh. We take a different approach, JavaScript loads the production/test code at the beginning and keeps them in the browser. It then reloads only the source files which have changed. This greatly speeds up test execution, since in most cases the browser only needs to re-parse a single file to re-run it.
• Full Control of DOM: Many JavaScript test harnesses report the test results into the DOM. This means that portions of the DOM can not be modified by the tests or you will lose the test result information. Since JsTestDriver reports the test status on the command line, tests are free to modify the DOM in any way they need for the test. JsTestDriver then resets the state of the DOM for the next test.
• Easy Configuration: JsTestDriver comes bundled as a single JAR file. There is no need to write HTML wrapper classes which have complex script tags inclusions to bootstrap the test runner. All you have to write is your source file, tests file, and a configuration file listing location of your source/test files and you are ready to go.
• Code Coverage: CodeCoverage can be computed for your tests
• Declarative HTML Injection: Need specific DOM to be loaded to your test executes, no problem: HtmlDoc

Overview

JsTestDriver consist of a single JAR file which contains everything you need to get started. For in depth discussion of command line option see GettingStarted.

Here is an overview of how JsTestDriver works at runtime:

1. You start off by launching the Server. The server is responsible for loading the test runner code into the browser and in the process turning the browser into a slave. Once the browser is a slave it can be controlled to do any action from the command line. In our case the server will send commands to the browser to load source code, execute arbitrary functions and report the results back to the requester. A single server can capture any number of browsers, even from other machines across the network. The server does not need to be on your development machine. This is useful if your primary development platform is different than your primary test platform. For example I develop code on mac but want to run my tests against Internet Explorer on Windows.
2. After you have a server running you can capture any number of browsers. The capturing process can be automatic through a command line option. In most cases you point your browser to the server by visiting the server URL. Once the browser is captured you can forget about the browser (minimize/hide it), since the server can run any number of tests on the browser for an indefinite period of time. A common use case is to capture the browsers once and then use them for the remainder of the development during that day. The only time you will need to interact with the browser is if you wish to debug code with the browser's debugger.
3. At this point you need write some source and tests code. There is no need to write any HTML wrappers, the code is normal JavaScript code with tests resembling JUnit. Once you have a test we are ready to run our tests.
4. One last thing you need to do is to create a configuration file. This file tells the JsTestDriver which JavaScript files need to be loaded into the browser and in which order (optionally, where the server is located.) Think of the configuration file as the Java classpath and your JavaScript files as JARs. The good news is that this file is usually very short since for most projects a single line which says load everything (we support globing) is sufficient.
5. You are now ready to run your tests. Form now on all you need to do is to rerun this last step to re-run the tests. The server is intelligent to reload only the files which have changed into the browser and in the right order. Since the browser is kept ready the test execute extremely fast. The effect is more noticeable as the project gets bigger.

See JsTestDriver in Action

http://www.youtube.com/watch?v=V4wYrR6t5gE

JsTestDriver for Eclipse

Update Site: http://js-test-driver.googlecode.com/svn/update/

More details: Eclipse plugin details

For IntelliJ IDEA

Look for JSTestDriver in the Plugin Manager inside IDEA.

Group

Question? Answers? Feature Requests? Bored? join our group: js-test-driver@googlegroups.com