I’ve just released a new version of the Loris gem 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 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

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(){
  ok(true);
});

My thanks go to anotherhero for providing the patch to fix both these issues.

You can always download the latest version of QUnitAdapter from Google Code.

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.

BrowserCacheIndicator.cs

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) {
			BrowserCacheIndicator.ClearCacheCookie(Response);
		}
	}
}

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!

browser-cache.js

// 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) {
		refreshBasket();
	}
});

Enjoy!

Issue 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.

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 and JS Test Driver whenever a file changes, it will report the results to the command line and using Growl. If required, Loris will automatically start the JS Test Driver server and register your default browser with it.

Installing

Loris is hosted on Gemcutter, 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

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.

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
 
load:
  - 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

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
success
All files are clean
 
0 error(s), 0 warning(s)
JS Test Driver
success
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 1.9.1.4 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 (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 or Growl for Windows. Growl for Windows requires the .NET Framework 2.0+.

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

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. Just load the adapter into JSpec as a normal javascript file, and you can nowexec() qunit test files in JSpec.

Downloading the QUnit to JSpec Adapter

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

QUnitToJSpecAdapter.js

/*
QUnitToJSpecAdapter
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() {
 
    JSpec.addMatchers({
        be_ok : '!!actual'
    });
 
 
    JSpec.context = JSpec.defaultContext;
    JSpec.context.QUnitAdapter = {
        modules: []
    };
 
    module = function(name, lifecycle) {
 
        JSpec.context.QUnitAdapter.modules.push({
            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) {
                            adapter.calledAsserts++;
                            JSpec.expect(actual).to(JSpec.matchers.be_ok);
                        },
 
                        equals: function(a, b, msg) {
                            adapter.calledAsserts++;
                            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' + 
                                'http://github.com/visionmedia/jspec/tree/master';
                        },
 
                        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' + 
                                'http://github.com/visionmedia/jspec/tree/master';
                        },
 
                        same: function(a, b, msg) {
                            adapter.calledAsserts++;
                            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() {
                QUnitAdapter.modules[0].tests.shift();
            });
 
            after(function() {
                QUnitAdapter.modules.shift();
            });
 
        });
 
    };
 
    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

module('Examples');
 
test('True is ok', function() {
  expect(1);
  ok(true);
});
 
module('Examples with lifecycle', {
  setup: function() {
    started = 'yes';
  },
  teardown: function() {
    ok(started);
    started = null;
  }
});
 
test('Test has started', function() {
  expect(2);
  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, andexec() 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

load('/Library/Ruby/Gems/1.8/gems/visionmedia-jspec-2.10.0/lib/jspec.js')
load('lib/QUnitAdapter.js')
 
JSpec
.exec('spec/qunit-tests.js')
.run({ formatter : JSpec.formatters.Terminal })
.report()

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 interference.

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

spec.dom.html

<html>
    <head>
        <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>
        <script>
            function runSuites() {
                JSpec
                .exec('qunit-tests.js')
                .run()
                .report()
            }
        </script>
    </head>
    <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>
    </body>
</html>

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
 
 Examples
  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.

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 themock timers that come with JSpec.

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 methods.

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 thesetup variable is lost.

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

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() {
	expect(1);
	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.

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.

• For each Build Agent
• Download Java and install it.
• Download the JS Test Driver jar and save it to c:\TeamCityBuildTools\JSTestDriver\ (or whichever location you wish)

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). E.g.

server: http://localhost:9876
 
load:
  # 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" />
 
  <PropertyGroup>
    <JSTestDriverJar>&quot;$(BuildToolsPath)\JSTestDriver\jsTestDriver.jar&quot;</JSTestDriverJar>
    <ConfigFile>&quot;$(SolutionFolder)\jsTestDriver.conf&quot;</ConfigFile>
    <IEPath>&quot;C:\Program Files\Internet Explorer\iexplore.exe&quot;</IEPath>
    <OutputDir>&quot;$(SolutionFolder)\output\JSTestDriver&quot;</OutputDir>
  </PropertyGroup>
 
  <Exec Command="java -jar $(JSTestDriverJar) --port 9876 --browser $(IEPath) --config $(ConfigFile) --tests all --testOutput $(OutputDir)" />
 
</Target>

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!

This fixes a bug where the ok() assertion was much stricter than the qunit equivalent. It was only succeeding when passed a boolean true value.

Now it behaves the same as the qunit version, and succeeds with all values other than 0, false, or null.

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

Some of these tests deal with time based logic, such as delayed callbacks or time limited user interaction. Currently these tests are run in a HTML page using qunit.

To deal with the time based logic I use the jsUnit’s Mock Timeout. See Simulating Time in jsUnit Tests on the Google Testing Blog.

jsUnit’s Mock Timeout overrides the built in setTimeout, clearTimeout, setInterval, and clearInterval methods, and provides a Clock object that allows you to control the passage of time.

Problem

This works fine in qunit, but it fails catastrophically in JS Test Driver. This is because JS Test Driver uses the setTimeout and setInterval methods to control it’s own behaviour. Once these have been overridden with the mock versions JS Test Driver no longer works.

As a temporary fix for this I have created a patched version of JS Test Driver, which creates it’s own copies of the original setTimeout, clearTimeout, setInterval, and clearInterval methods, before loading any code. This ensures it works well with the jsUnit Mock Timeout.

Patched JS Test Driver

Download a patched JsTestDriver with no-confilict timeouts.

Just use this jar in place of the original JsTestDriver-1.0b.jar, and you can include jsUnitMockTimeout.js in your tests without breaking JS Test Driver!

You may also want to download jsUnitMockTimeout.js (to save you finding it within the jsUnit source).

The Future

I see this patched JS Test Driver as very much a temporary stepping stone, while the correct solution is worked out. Beware of relying on it too heavily!