Home / Blog /

A few months ago [I wrote about Loris](http://monket.net/blog/2009/11/loris-autotest-for-javascript/), a small tool that will automatically run your javascript tests whenever a file changes.

I’ve just released a new version of the [Loris gem](http://rubygems.org/gems/loris) with a couple of minor fixes:

* The dependency on `win32-process` has now been removed from the gem. This means the gem now installs correctly on OSX. Windows users will manually need to install the `win32-process` gem.

* The dependancy on `visionmedia-bind` has been updated to just `bind`, reflecting the gems new name on RubyGems.

* The JS Test Driver server is now reset between all tests. This stops it getting into a situation where it failed to pick up changes to files.

Because [RubyGems](http://rubygems.org/) is now the default gem host, this install process is a little simpler.

sudo gem install loris

or on Windows

gem install loris
gem install win32-process

QUnitAdapter 1.1.0

April 9th, 2010

I’ve updated the JS Test Driver [QUnitAdapter](http://code.google.com/p/js-test-driver/wiki/QUnitAdapter) to improve compatibility with QUnit.

Variables set on the `this` object within are now available within setup, teardown, and the tests themselves.

module('Lifecycle', {
  setup: function() {
    this.mockString = "some string";
  teardown: function() {
    equals(this.mockString, "some string");
test("Things assigned to this in setup are available in test", function() {
  equals(this.mockString, "some string");

The `test` function now supports the optional second parameter of the expected number of assertions.

// declare that this test has expects 1 assertion
test('Test with expected defined as 2nd param', 1, function(){

My thanks go to `anotherhero` for providing the [patch](http://code.google.com/p/js-test-driver/issues/detail?id=116) to fix both these issues.

You can always [download the latest version of QUnitAdapter from Google Code](http://code.google.com/p/js-test-driver/wiki/QUnitAdapter).

When a user presses the back button in their browser to return to a previous page, that page is usually loaded straight from the browser’s cache, without any requests being made to the server. When that page shows information that could be out of date (such a an old list of products in your basket) this can cause problems.

So how about we knock up a little code that allows us to determine whether the page has been loaded from the server or the browsers cache. Then we can reload those parts of the page that may need updating (such as the basket).

We can do this by setting a cookie on every response from the server, and modifying that cookie using javascript. We can then use this cookie to know whether the page has been loaded from the server or the browser cache.

##Setting the cookie on every response from the server

We will use a `loadedFromBrowserCache` cookie to facilitate the cache detection. We will set it to `false` every time a page is loaded from the server.

You can use the `BrowserCacheIndicator` class below to manage the cookie.


using System.Web;
namespace SevenDigital.Web.Com.Code {
	public class BrowserCacheIndicator {
		private const string CACHE_COOKIE = "loadedFromBrowserCache";
		// This works with the javascript on the site to determine whether
		// a page has been loaded from the browser cache
		// *Every time* a page is loaded from the server we need to set
		// the loadedFromBrowserCache cookie to false
		// This method should be called in all Master Pages
		public void ClearCacheCookie(HttpResponse response) {
			response.SetCookie(new HttpCookie(CACHE_COOKIE, "false"));

And then set the cookie in every Master page:

namespace SevenDigital.Web.Com {
	public partial class ExampleMasterPage: BaseMasterPage {
		protected readonly BrowserCacheIndicator BrowserCacheIndicator = new BrowserCacheIndicator();
		protected void Page_Load(object sender, EventArgs e) {

##Using the cookie to know whether the page was loaded from the browser cache

The `loadedFromBrowserCache` cookie will be reset set to `false` by the HTTP Response header every time the page is loaded from the server. But it will not be reset when the page is loaded from the cache. We can use this to our advantage by setting the `loadedFromBrowserCache` cookie to `true` in javascript.

Then we know that the browser was loaded from the cache if the cookie is true on page load (because it was not reset by the server).

We just need to make sure we check the cookie before we set it to `true`!


// Detect whether or not we are loading this page from the browser cache
// Set the value $.loadedFromBrowserCache, which other scripts can use
(function() {
	var CACHE_COOKIE = 'loadedFromBrowserCache';
	jQuery.loadedFromBrowserCache = getCookie(CACHE_COOKIE) == 'true';
	setCookie(CACHE_COOKIE, 'true');

Now we have a `$.loadedFromBrowserCache<` variable that let's us know whether the page was loaded from the browser cache.

Note, the above function can run immediately, it does not need to wait for the `jQuery` `ready` event, or the `window.onload` event as it does not modify the DOM.

##Using `$.loadedFromBrowserCache` to do something useful

Now we can do something useful with the knowledge a page was reloaded from the cache. How about reloading the users basket to ensure it is always up to date:

// Reload the basket using ajax
// This is so that users still see the latest basket when using the back
// button in their browsers
$(function() {
	if ($.loadedFromBrowserCache) {


QUnitAdapter 1.0.3

November 10th, 2009

Just a small update to the JS Test Driver [QUnitAdapter](http://code.google.com/p/js-test-driver/wiki/QUnitAdapter). Version 1.0.3 has been released, and fixes a single bug:

**[Issue 64](http://code.google.com/p/js-test-driver/issues/detail?id=64): QUnit Adapter fails to run tests if you don’t include a module**

You can now declare tests without a module, and they will run under the `Default Module`. In previous versions these tests would be silently ignored (whoops!).

You can always [download the latest version of QUnitAdapter from Google Code](http://code.google.com/p/js-test-driver/wiki/QUnitAdapter).

Loris: Autotest for Javascript

November 6th, 2009

I’ve [previously written a number of posts on javascript and autotest](http://monket.net/blog/tag/autotest/). Explaining how to integrate javascript lint, unit tests, and growl with the ruby [Autotest](http://ph7spot.com/articles/getting_started_with_autotest) project.

While this all worked, it felt a little clunky as Autotest doesn’t natively support the idea of running multiple tasks one after the other. Rather than hack at the Autotest codebase, I thought I’d get some ruby experience by rolling my own autotest-style framework. Not great for reuse of code, but a great way for me to learn :)

## Loris

Loris will monitor your project and run [Javascript Lint](http://www.javascriptlint.com/) and [JS Test Driver](http://code.google.com/p/js-test-driver/) whenever a file changes, it will report the results to the command line and using [Growl](http://growl.info/). If required, Loris will automatically start the JS Test Driver server and register your default browser with it.

### Installing

Loris is hosted on [Gemcutter](http://gemcutter.org/), so you need to install their gem if you haven’t already.

sudo gem update --system
sudo gem install gemcutter
gem tumble

Then to install Loris, just run the following:

sudo gem install loris

Loris has no command line options, and no configuration file (at the moment). It looks for configurations files to decide which tasks to run.

### Configuring Javascript Lint

To enable Javascript Lint, create a `jsl.conf` file in the folder where you run Loris. This should be a standard Javascript Lint config file. If you need here is an [example Javascript Lint config file](http://mike.kruckenberg.com/archives/2009/03/configuration-options-for-javascript-lint.html)

You just need to specify which files Javascipt Lint should process. For example:

### Files
# Specify which files to lint
# Use "+recurse" to enable recursion (disabled by default).
# To add a set of files, use "+process FileName", "+process Folder\Path\*.js",
# or "+process Folder\Path\*.htm".
+process src/js/*.js
+process tests/js/*.js

If no `jsl.conf` file is found, the Javascript Lint task is silently skipped.

### Configuring JS Test Driver

To enable JS Test Driver, create a `jsTestDriver.conf` file in the folder where you run Loris. This should be a standard [JS Test Driver config file](http://code.google.com/p/js-test-driver/wiki/ConfigurationFile).

This should specify which files JS Test Driver should process, and how it connects to the JS Test Driver server. For example:

server: http://localhost:9876

  - tests/qunit/equiv.js
  - tests/qunit/QUnitAdapter.js
  - src/js/*.js
  - tests/js/*.js

If no `jsTestDriver.conf` file is found, the JS Test Driver task is silently skipped.

To make it really simple to run JS Test Driver tests, if the server is set to run on `localhost`, and Loris doesn’t detect one running, it will automatically start one, and register your default browser with it.

This makes it a one step process to get automated tests up and running.

### Running

To run, open a command line window, navigate to the root folder of your project, and run:


Loris will run Javascript Lint, and JS Test Driver tasks (if it finds their configuration files), and will output the results on the command line.

#### Example output

Javascript Lint
All files are clean
0 error(s), 0 warning(s)
JS Test Driver
All tests pass
[PASSED] GreeterTest.testGreet
  [LOG] JsTestDriver Hello World!
[PASSED] GreeterTest.testGoodbye
[PASSED] GreeterTest.testSetName
[PASSED] GreeterTest.testSetNameAndNameParamter
[PASSED] Asserts.test OK true succeeds
[PASSED] Asserts.test Equals succeeds
  [LOG] about to call assertEquals
[PASSED] Asserts.test Same assert succeeds
[PASSED] Lifecycle.test Setup and Teardown are run, and can contain assertions
Total 8 tests (Passed: 8; Fails: 0; Errors: 0) (3.00 ms)
  Firefox MacIntel: Run 8 tests (Passed: 8; Fails: 0; Errors 0) (3.00 ms)

Every time you make a change to a Javascript file, or a configuration file, Loris will automatically re-run Javascript Lint and JS Test Driver. So you can instant feedback on your changes.

Loris will clear the command line when re-running tasks. So the latest run is always at the top of you command line.

Loris will also report a summary of each task using [Growl](http://growl.info/) (if it is installed). This allows you to get quick feedback without needing to refer back to the command line on every change.

### Requirements

JS Test Driver is written in Java, so you will need to have Java installed to run it.

To get Growl notifications, you will need to install either [Growl for OSX](http://growl.info/) or [Growl for Windows](http://www.growlforwindows.com/). Growl for Windows requires the [.NET Framework 2.0+](http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5&displaylang=en).

### Caveat

Loris is pretty limited at the moment, I just wired up the basics to get it running for a work project.

It doesn’t have any configuration options at the moment, so you have to follow it’s assumptions for now. I’m happy to add configuration options for any element as required.

Loris only comes with a few tasks (Javascript Lint, JS Test Driver, JSpec, and RSpec), but I hope to allow it have new tasks added via new gems (kind of similar to Autotest).

It comes packaged with a version of Javascript Lint, and JS Test Driver, and will use it’s own versions. It only includes the OSX and Windows versions of Javascript Lint.

If you want to modify the code, just fork the [Loris github project](http://github.com/karl/loris)

At 7digital we use [Cucumber](http://cukes.info/) and [Watir](http://wtr.rubyforge.org/) for running acceptance tests on some of our websites.

These tests can help greatly in spotting problems with configuration, databases, load balancing, etc that unit testing misses.

But because the tests exercise the whole system, from the browser all the way through the the database, they can tend be flakier than unit tests. Then can fail one minute and work the next, which can make debugging them a nightmare.

So, to make the task of spotting the cause of failing acceptance tests easier, how about we set up Cucumber to take a screenshot of the desktop (and therefore browser) any time a scenario fails.

## Install Screenshot Software

The first thing we need to do is install something that can take screenshots. The simplest solution I found is a tiny little windows app called [SnapIt](http://90kts.com/blog/2008/capturing-screenshots-in-watir/). It takes a single screenshot of the primary screen and saves it to a location of your choice. No more, no less.

* [Download SnapIt](http://90kts.com/blog/wp-content/uploads/2008/06/snapit.exe) and save it a known location (e.g. `C:\Tools\SnapIt.exe`)

## Tell Cucumber to Take a Screenshot When a Scenario Fails

Now we need to tell Cucumber to take a screenshot. To do so we’ll add a function to the Cucumber `World` that will take a screenshot if needed, and run this in the `After` scenario hook. To do this modify your `features/support/env.rb` file.

#### env.rb

class DefaultWorld
  # Screenshot directory, relative to this env.rb file
  DEFAULT_SCREENSHOT_PATH = File.expand_path(File.dirname(__FILE__) + '/../../../output/cucumber/screenshots/')
  # Absolute location of SnapIt
  SNAPIT_PATH = 'C:\\Tools\\SnapIt.exe'
  def take_screenshot_if_failed(scenario)
    if (scenario.status != :passed)
      scenario_name = scenario.to_sexp[3].gsub /[^\w\-]/, ' '
      time = Time.now.strftime("%Y-%m-%d %H%M")
      screenshot_path = DefaultWorld::DEFAULT_SCREENSHOT_PATH + '/' +  time + ' - ' + scenario_name + '.png'
      cmd = DefaultWorld::SNAPIT_PATH + ' "' + screenshot_path + '"'
  # [...] Other DefaultWorld code here if needed
World do
After do |scenario|
  # [...] Other After hook code here if needed  

Just modify the constants in the above code to point to the locations of SnapIt and a directory to save the screenshots too.

## What the Code Does

The code will only take a screenshot if the scenario fails to pass.

It then extracts the name of the scenario, and converts it to a filename friendly string (e.g. `Monkey’s should eat “things”` => `Monkey s should eat things`). It then prepends the current date and time, and uses this string as the filename for the screenshot.

This allows you to easily find screenshots for a specific scenario or time.

## Run a Failing Test and Check Out the Screenshot

Now you can run Cucumber as normal, watch a test fail, and you should see a screenshot appear in the directory you specified. And hopefully it will help you work out what went wrong, enjoy!

If the screenshot fails to appear, it could be because of an error in the ruby code. But Cucumber seems to hide any execptions within the After hook, so you may need to add `puts` statements to work out what is going wrong.

[TeamCity](http://www.jetbrains.com/teamcity/) is a great continuous integration server, and has brilliant built in support for running [NUnit](http://www.nunit.org/) tests. The web interface updates automatically as each test is run, and gives immediate feedback on which tests have failed without waiting for the entire suite to finish. It also keeps track of tests over multiple builds, showing you exactly when each test first failed, how often they fail etc.

If like me you are using [Cucumber](http://cukes.info/) to run your acceptance tests, wouldn’t it be great to get the same level of TeamCity integration for every Cucumber test. Well now you can, using the `TeamCity::Cucumber::Formatter` from the TeamCity 5.0 EAP release.

JetBrains, the makers of TeamCity, released a [blog post demostrating the Cucumber test integration](http://blogs.jetbrains.com/ruby/2009/08/testing-rubymine-with-cucumber/), but without any details in how to set it up yourself. So I’ll take you through it here.

## Getting a Copy of the TeamCity Cucumber Formatter

The [latest TeamCity EAP](http://www.jetbrains.net/confluence/display/TW/TeamCity+EAP) contains the new Cucumber Formatter hidden deep in it’s bowels. Rather than make you wade through it all, I’ve extracted the relevant files and they are available to download here:

#### [Download the TeamCity Cucumber Formatter](http://monket.net/blog/wp-content/uploads/2009/09/TeamCityCucumberFormatter.zip)

The archive contains the formatter and the TeamCity library files it requires to run. Extract the archive in your project root and it will add the following files:

        [some support and utility files]

If you want to locate these files within the TeamCity EAP yourself, [download the TeamCity 5.0 EAP War](http://download.jetbrains.com/teamcity/TeamCity-10307.war) file and extract it. Then from within the war unzip `WEB-INF/plugins/rake-runner-plugin.zip`. And from within the rake-runner-plugin look at `rake-runner/lib/rb/patch/bdd/teamcity/cucumber/formatter.rb` and all the files in `rake-runner/lib/rb/patch/common/teamcity/`.

The formatter in my download has been tweaked to look in a new location for the teamcity support files, and has been changed to be a single class in a module named `JBTeamCityFormatter` (to ease calling it from the command line).

The relevant changes in the file are:

$: << File.expand_path(File.dirname(__FILE__) + '/../../lib/')
require 'teamcity/runner_common'
require 'teamcity/utils/service_message_factory'
require 'teamcity/utils/runner_utils'
require 'teamcity/utils/url_formatter'
class JBTeamCityFormatter < ::Cucumber::Ast::Visitor

## Setting up Cucumber to use the TeamCity Formatter

Once you have the formatter installed you can use it as with any Cucumber formatter by adding it as a command line parameter:

cucumber features -f JBTeamCityFormatter

To use it with TeamCity, add a profile your `cucumber.yml` file that runs all your features using the new formatter:

#### cucumber.yml

default: features -q 
teamcity: features -q --no-c  -f JBTeamCityFormatter

## Running Cucumber with TeamCity

Now when you run Cucumber within TeamCity (using the `teamcity` profile) it will report tests in real time, with all the feedback you are used to. Just add a call to the Cucumber executable to your build script (NAnt, MSBuild, Ant, Rake, etc).

![Cucumber tests in TeamCity](http://monket.net/blog/wp-content/uploads/2009/09/cucumber-tests-in-teamcity-cropped.png)

Enjoy the new found treatment of Cucumber tests as first class citizens in TeamCity!

QUnit to JSpec Adapter

September 3rd, 2009

[JSpec][1] is a Javascript BDD framework with a lot of great things going for it: It can run without a browser (great for continuous integration servers), it
has a Ruby style custom syntax which makes tests easier to write and read, and
it uses a BDD style describe/should syntax.

[1]: http://visionmedia.github.com/jspec/

It’s a very tempting framework to use, but I already have a large collection
of tests using qunit. I don’t want to use two frameworks for one project, and I
don’t want to rewrite 300+ tests, so what to do?

How about a QUnit to JSpec Adapter, in the vein of my
[QUnit to JS Test Driver Adapter][2]. Just load the adapter into JSpec as a
normal javascript file, and you can now`exec()` qunit test files in JSpec.

[2]: http://monket.net/blog/2009/06/new-qunit-to-js-test-driver-adapter/

## Downloading the QUnit to JSpec Adapter

First up [download the QUnit to JSpec Adapter][3], or copy the code below, and
save it somewhere in your project (e.g. a `lib` folder).

[3]: http://monket.net/blog/wp-content/uploads/2009/09/QUnitToJSpecAdapter.js

#### [QUnitToJSpecAdapter.js][3]

Version: 1.0.0
Run qunit tests using JSspec
This provides almost the same api as qunit.
Tests must run sychronously, which means no use of stop and start methods.
You can use the JSpec mock timers to deal with timeouts, intervals, etc
The qunit #main DOM element is not included. If you need to do any DOM manipulation
you need to set it up and tear it down in each test.
(function() {
        be_ok : '!!actual'
    JSpec.context = JSpec.defaultContext;
    JSpec.context.QUnitAdapter = {
        modules: []
    module = function(name, lifecycle) {
            name: name,
            tests: [],
            setup:    (lifecycle && lifecycle.setup)    ? lifecycle.setup    : function() {}, 
            teardown: (lifecycle && lifecycle.teardown) ? lifecycle.teardown : function() {}
        JSpec.describe(name, function() {
            var length = QUnitAdapter.modules[0].tests.length;
            for (var i = 0; i < length; i++) {
                it(QUnitAdapter.modules[0].tests[i].name, function() {
                    var adapter = {
                        expectedAsserts: 0,
                        calledAsserts: 0,
                        expect: function(count) {
                            adapter.expectedAsserts = count;
                        ok: function(actual, msg) {
                        equals: function(a, b, msg) {
                            JSpec.expect(a).to(JSpec.matchers.be, b);
                        start: function() {
                            throw 'start and stop methods are not available when using JSpec.\n' +
                                'Use the JSpec timer to deal with timeouts and intervals:\n' + 
                        stop: function() {
                            throw 'start and stop methods are not available when using JSpec.\n' +
                                'Use the JSpec timer to deal with timeouts and intervals:\n' + 
                        same: function(a, b, msg) {
                            JSpec.expect(a).to(JSpec.matchers.eql, b);
                        reset: function() {
                            throw 'reset method is not available when using JSpec';
                        isLocal: function() {
                            return false;
                    eval('with(adapter) {' +
                        JSpec.contentsOf(QUnitAdapter.modules[0].setup) +
                        'try {' +
                        JSpec.contentsOf(QUnitAdapter.modules[0].tests[0].testCallback) +
                        '} catch(ex) { throw(ex); } finally {' +
                        JSpec.contentsOf(QUnitAdapter.modules[0].teardown) +
                        '} }');
                    if (adapter.expectedAsserts > 0) {
                        JSpec.expect(adapter.calledAsserts).to(JSpec.matchers.equal, adapter.expectedAsserts);
            after_each(function() {
            after(function() {
    test = function(name, testCallback) {
        JSpec.context.QUnitAdapter.modules[JSpec.context.QUnitAdapter.modules.length - 1].tests.push({
            name: name,
            testCallback: testCallback

## Having some QUnit tests

First up you need some qunit tests. Having the qunit test files in the `spec`
directory helps simplify loading them.

As an example you can use the following:

#### qunit-tests.js

test('True is ok', function() {
module('Examples with lifecycle', {
  setup: function() {
    started = 'yes';
  teardown: function() {
    started = null;
test('Test has started', function() {
  equals(started, 'yes');

## Configuring QUnit Support

Then to enable QUnit tests to be run in JSpec, you must have JSpec load the
adapater as a normal javascript file, and`exec()` the QUnit test file as you
would a JSpec spec file.

For JSpec rhino support your `spec.rhino.js` file would look like:

#### spec.rhino.js

.run({ formatter : JSpec.formatters.Terminal })

Notice how the QUnit test file is exec’d exactly as you would a normal spec
file. You can run specs and Qunit tests along side each other without any

And for running the tests within a browser your `spec.dom.html` file would look

#### spec.dom.html

        <link type="text/css" rel="stylesheet" href="/Library/Ruby/Gems/1.8/gems/visionmedia-jspec-2.2.1/lib/jspec.css" />
        <script src="/Library/Ruby/Gems/1.8/gems/visionmedia-jspec-2.2.1/lib/jspec.js"></script>
        <script src="../lib/QUnitAdapter.js"></script>
            function runSuites() {
    <body class="jspec" onLoad="runSuites();">
        <div id="jspec-top"><h2 id="jspec-title">JSpec <em><script>document.write(JSpec.version)</script></em></h2></div>
        <div id="jspec"></div>
        <div id="jspec-bottom"></div>

## Running the tests

To run the tests just launch JSpec as normal. My prefered method is to run the
tests using rhino, to do this navigate to your project root directory in a
terminal window and run:

jspec run --rhino

And you should now see your QUnit tests running in JSpec:

 Passes: 5 Failures: 0
  True is ok..
 Examples with lifecycle
  Test has started...

## Limitations

This adapter has many of the same limitations and my
[QUnit to JS Test Driver adapter][1].

[1]: http://monket.net/blog/2009/06/new-qunit-to-js-test-driver-adapter/

The tests must run synchronously (which means no use of the qunit `stop` and
`start` methods).

If you need to test timeouts, intervals, or other asynchronous sections of code
, you can use the[mock timers that come with JSpec][2].

[2]: http://github.com/visionmedia/js-mock-timers/tree/master

QUnit DOM support is not included. Consider avoiding interacting directly with
the browser within your unit tests. But if you do need to, you’ll need to create
and remove the DOM objects yourself with each test, or the setup and teardown

And lastly, tests are broken out of any closures before they run. This means
they lose access to any closure variables. For example, the follow test would
work in QUnit, but not in JSpec. When running in JSpec access to the`setup`
variable is lost.

  var setup = function() {
    // do setup...
  test('name', function() {

QUnit Adapter 1.0.2

August 30th, 2009

A new version of the JS Test Driver QUnit Adapter is available.

Version 1.0.2 fixes a small bug where a module lifecycle object without Setup or Teardown methods would cause a test to error. For example:

module('Lifecycle', {});
test('', function() {
	ok(true, 'tests still run successfully even if Setup and Teardown are undefined');

Would give the error Lifecycle.test error (1.00 ms): Result of expression 'l.setUp' [undefined] is not a function..

This is now fixed so the test behaves as if no lifecycle was defined.

You can get the new 1.0.2 verison of the QUnit Adapter from Google Code.

JS Test Driver is a great new Javascript Testing Framework from the guys at Google. It provides a blisteringly fast, and easily automated way of running your Javascript unit tests. See this introduction to JS Test Driver by Miško Hevery for a great overview.

Getting JS Test Driver up and running on your development workstation is easy enough. But how about on a continuous integration server such as TeamCity?

It’s easy, just follow the instructions below!

Install Java and the JS Test Driver jar on all the build agents

JS Test Driver is packaged as a Java jar, and therefore all the TeamCity build agents will need a copy of Java and the JS Test Driver jar in order to run the tests.

Configure JS Test Driver

This guide assumes you already have JS Test Driver and some tests set up on your local machine. If not see this introduction to JS Test Driver by Miško Hevery.

Just make sure that the JS Test Driver config file is set to connect to the local machine, on port 9876 (on another port of your choice).

server: http://localhost:9876
  # list of files to load here...

Configure your build process to call JS Test Driver

Now that we have JS Test Driver installed on our build machines, and configured correctly, let’s call it from our build process. At 7digital we are using MSBuild, so we can create a JSTestDriver Target as so:

<Target Name="JSTestDriver">
  <Message Text="##teamcity[progressMessage 'Running JS Test Driver']" Importance="high" />
  <Message Text="-------- Running JS Test Driver --------" Importance="high" />
    <IEPath>&quot;C:\Program Files\Internet Explorer\iexplore.exe&quot;</IEPath>
  <Exec Command="java -jar $(JSTestDriverJar) --port 9876 --browser $(IEPath) --config $(ConfigFile) --tests all --testOutput $(OutputDir)" />

The important points here are that you have the properties configured correctly (JSTestDriverJar, ConfigFile, etc) for your individual setup.

The Exec command will automatically create a JS Test Driver server, launch IE, and run all the tests. The test results will be output to the OutputDir in a JUnit compatible xml format. See the JS Test Driver continuous integration page for more information.

Once you have created this Target, ensure it is called by your standard bulid Target by adding it as a dependancy:

<Target Name="BuildAndUnitTest" DependsOnTargets="Compile;JSLint;JSTestDriver;NUnit" />

Have TeamCity pick up the test results

If you run your build through TeamCity now, you will see that it runs all your Javascript tests using JS Test Driver. But it doesn’t report any results. And test failures don’t stop the build.

Luckily TeamCity can import the JS Test Driver output xml, because it is JUnit compatible.

  • Select the build which is running the JS Test Driver tests
  • Click Edit Configuration Settings
  • Click on build step 3 (e.g. Runner: MSBuild)
  • Under the XML Report Processing section, choose Ant JUnit from the Import data from dropdown
  • In the Report paths text area add the relative path the the JS Test Driver output file (e.g. output\JSTestDriver\TEST-com.google.jstestdriver.1.xml)
  • Click save!

Now when you run your build again you will see your JS Test Driver tests showing up in the Tests tab, and test failures now stop the build.

Your Javascript unit tests now sit as first class citizens within TeamCity!