We decided to use Jasmine, a behaviour driven development framework which tests can be run headless in a Maven build for example.
The second question was: How to visualise code coverage and code quality?
- Eclipse and IntelliJ integration
- Maven Plugin
- parallel test executions across browsers (local or remote)
- code coverage
In order to run JsTestDriver you have to create a config file. By default you have to name it jsTestDriver.conf and you have to save it in src/test/resources. If you want to choose another filename or path remember to define these in the Maven plugin later.
In the config file you have to define following flags (Be sure that there are no whitespaces in front of the keywords):
server: http://localhost:9876 load: # jasmine dependency - lib/jasmine.js # to make our jasmine tests work within jstd # (must be included after jasmine.js) - lib/jasmineAdapter.js # models, views and other stuff - src/main/js/*.js test: # load all test files - src/test/js/*Test.js plugin: - name: "coverage" jar: "lib/coverage-1.3.4.b.jar" module: "com.google.jstestdriver.coverage.CoverageModule"
JsTestDriver starts it’s own server and generates a HTML page that can be captured by various browsers.
simply attaches the test files to the created HTML page.
to be able to see the code coverage report in Sonar you have to download the coverage plugin and save it somewhere as you wish. Just remember to add the path to the plugin jar flag as shown in the listing above.
Before we can see the Sonar report about the code quality and code coverage we have to configure maven to run jstd.
Unfortunately, the jstd-maven-plugin is not available at the Maven Central Repository. Therefore we have to add a new repository and pluginRepository to our pom.xml:
<repository> <id>jstd-maven-plugin google code repo</id> <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url> </repository> <pluginRepository> <id>jstd-maven-plugin google code repo</id> <url>http://jstd-maven-plugin.googlecode.com/svn/maven2</url> </pluginRepository>
After that maven should be able to fetch the jstd-maven-plugin artifact:
<dependency> <groupId>com.googlecode.jstd-maven-plugin</groupId> <artifactId>jstd-maven-plugin</artifactId> <version>188.8.131.52</version> <scope>test</scope> </dependency>
To run our tests with a maven build we need the jstd-maven-plugin as a Maven plugin:
<plugin> <groupId>com.googlecode.jstd-maven-plugin</groupId> <artifactId>jstd-maven-plugin</artifactId> <version>184.108.40.206</version> <configuration> <browser>firefox</browser> <port>9876</port> <testOutput>target/jstestdriver</testOutput> </configuration> <executions> <execution> <id>run-tests</id> <goals> <goal>test</goal> </goals> </execution> </executions> </plugin>
Three configuration flags are mandatory. More command line flags can be found in the documentation of jstd.
a comma separated list of browsers (more exactly the path to the specific browser) that should be used for the tests
the port that is set in jsTestDriver.conf
This specifies the directory where the code coverage reports (needed for Sonar) will be saved. The default directory for sonar is target/jstestdriver, so remember to configure sonar accordingly, if you choose another directory.
Set the sourceDirectory in the pom.xml
<build> <sourceDirectory>src/main/js</sourceDirectory> <!-- ... --> </build>
Run the tests and the analysis
Everything should be configured correctly now. So just start the maven build:
JsTestDriver opens the defined browsers, runs all tests and generates the code coverage report. After that we have to start the sonar build:
mvn sonar:sonar -Dsonar.language=js -Dsonar.branch=js
An annoying problem is running the tests with real browsers like Firefox and Chrome. The maven build automatically starts the browser and also closes it after the tests are finished. But Firefox is not correctly closed by jstd somehow… so the next test run fails because Firefox opens a dialog which must be closed manually. The maven build is deadlocked and you have to abort and rerun it…
So maybe a running Firefox process would be a workaround, I thought. Well, it kinda worked but the opened tab was not closed anymore (tested on Linux and Windows). Each new test run opened a new tab and after a handful testruns the tests failed because of some strange error. Closing tabs manually solved this, however. Same problem occurred with Chrome (Version 22.0.1201.0 dev).
automate the analysis within a Jenkins build process
— maybe jstd tests can be run headless?
— maybe maven profiles could be used to prevent the sourceDirectory declaration?
require.js integration in jstd-unit-tests