Small Update to Loris (0.1.3)

12. April 2010

A few months ago I wrote about Loris, 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 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

QUnitAdapter 1.1.0

09. April 2010

I’ve updated the JS Test Driver 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 to fix both these issues.

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

Detecting when a page is loaded from the browser cache

12. February 2010

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.


Loris Autotest for Javascript

06. November 2009

I’ve previously written a number of posts on javascript and autotest. Explaining how to integrate javascript lint, unit tests, and growl with the ruby 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 :)


Screenshots of Failing Cucumber Scenarios

14. September 2009

At 7digital we use Cucumber and Watir 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.


Cucumber Tests as First Class Citizens in TeamCity

03. September 2009

TeamCity is a great continuous integration server, and has brilliant built in support for running NUnit 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 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, but without any details in how to set it up yourself. So I’ll take you through it here.


QUnit to JSpec Adapter

03. September 2009

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

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.


QUnit Adapter 1.0.2

30. August 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.

Running JS Test Driver in Team City

25. August 2009

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!