agile42

Blog

The Optimal UnitTesting environment II

In the [last episode](http://agile42.com/cms/blog/2009/07/1/optimal-unittesting-environment/) I talked about the huge difference it makes to automate the execution of [unit tests](http://en.wikipedia.org/wiki/Unit_testing) on each file save.

On
6 July 2009
In
Scrum, Training
Tags
browsers, qunit, unittesting

In the last episode I talked about the huge difference it makes to automate the execution of unit tests on each file save.

This is all great and good - if you have the luxury to work with a language which can be reached from the shell.

Since we work with lots of JavaScript in the development of Agilo for Scrum, we have a problem. Of course there are tools like Narwhal that make it much easier to also run JS from the shell, but its not the same, and also it's very hard to debug javascript in there if it fails. (printf-debugging anyone?)

So, we looked for a different solution - and we found one that is quite workable for now.

First the setup though: We currently write most of our JavaScript tests in QUnit, which is itself quite a workable JavaScript unit testing framework. It runs in a webpage, where it also generates ok-ish output, most important, it has a very big red/green bar at the top of the window and a list of tests it executed below that. This makes it easy to run the tests in many browsers / version / virtual machines and also quite fast.

Of course, this setup makes it impossible for the JavaScript or the browser to detect if one of the included files did change in the filesystem. I was tinkering with making the browsers reload via a shell script, but I couldn't get it to work reliably with all browsers, so we choose a much simpler solution - we just re-run the entire testsuite every 3 seconds.

True this wastes some cycles - but it works like a charm. :)

Here's all it takes:

$(document).ready(function(){
    setTimeout("window.location.reload()", 3000);
});

Of course being the perfectionists we are, we went a little further to make it easy to stop the testrunner temporarily to debug a test or examine some state. So here's what we did turn out with.

I'd like to add that you should add ?noglobals to the url of the testrunner in all your bookmarks to it, so you find when you are leaking global variables - a type of JavaScript error which can be horrendously hard to find otherwise.

Subscribe to new blog posts

Did you find this article valuable? To be promptly noticed of new blog posts by agile42 you can subscribe to our notification system via email, powered by FeedBurner.

Enter your email address:

Discussion Comments are closed.

Comments are closed.

Comments are closed.

Comments have been closed for this post.

Latest entries

Executive Panel Discussion at MHA2015

Full recording of the MHA2015 Executive Panel Discussion at Mile High Agile 2015 in Denver, sponsored ...

 

Scrum certification trainings in the Netherlands

English language CSM and CSPO classes with Scrum Alliance certified trainers in Alphen aan den Rijn, ...

 

Talking about Portfolio Prioritization with Lean Canvas at PMI in Buffalo, NY

Projects are too often prioritized based on opinions and politics. Use the Lean Canvas, a one-page ...

 

Injecting advanced questions

An Agile coach can help a Scrum ceremony by injecting advanced questions, to help the team ...

 

Talking about Agile Transformations at Keep Austin Agile 2015

Dhaval Panchal presentation "Measuring What Matters in Your Agile Transformation" at Keep Austin Agile 2015, focusing ...