The optimal UnitTesting environment

1 July 2009 mhaecker

I want to tell you about the joys of automation today - the joy of having your test run just whenever you save one of your files.

By

mhaecker

On

1 July 2009

In

General, Scrum

Rate

Tags

tdd, unittesting

• Follow us on Twitter
• Our Facebook page
• Agilo Google Group
• Blog RSS Feed

I want to tell you about the joys of automation today - the joy of having your test run just whenever you save one of your files.

Because this is the thing - you cannot deliver high quality software with your Scrum implementation every month without having great engineering practices. If you don't have them, you can still deliver something every month and know exactly where you stand - but the quality will not be there. This is where practices like Unit Testing and Test Driven Development come in, as they are some of the best ways to improve quality that we as software professionals have found till today.

Unit Testing is all about getting more feedback about the code you are writing faster - this is the core of why it is so spectacularly productivity and quality enhancing.

In essence you open up a conversation with your code where you have

• Higher bandwidth than just looking at compiler output, because you write tests that tell you specific data points about your code when they fail. Also with many scripting languages like JavaScript or php for example you tend to get very little useful information from the interpreter to beginn with.
• Faster, because tests don't need to click through some UI or navigate a command line interface to test that specific thing you are working on right now.
• More input, because it makes sense to run those tests much more often than just compiling the code itself.

This last point however becomes very repetitive very fast - and this is where it makes the most sense to apply the old rule of "Three strikes and you automate".

This is what I want to talk about: tools that run your unit tests each time you save a file.

I can't even beginn to tell you in writing how powerful this is - you really have to try it to see how addictive it is.

Here's how it works:

• You instruct your auto test runner where your code lives and how it should run your unit tests
• You leave that terminal window open in the background
• You hack away in your editor and
• Voilá as soon as you save a file your tests get run

This saves you some seconds and brain cells each time you want to run your tests - and of course it also means that you run them even more often which helps again with the feedback cycle.

The mother of all tools for this kind of test automation is of course rubys ZenTest which is so good, because it not only re-runs your tests whenever you change a file, but also really understands the structure of the source, and therefore can for example randomize the order in which your tests are run. This is just great for finding brittle tests that depend on each other. It has other features too, for example allowing you to run just those tests that are affected by a specific change (I have no Idea how they solved the halting problem to do that, but apparently it works very well).

For other languages I havent yet found such an intricate tool yet (I'd love to hear from whoever knows something!) - however there are multiple tools around that just let you run a specific command whenever some file changes in a hierarchy.

Here's some examples:

• My coworker Felix Schwarz wrote a python tool that we use internally to develop the Scrum tool Agilo. It is great because you don't have to restart it when new files are added to the project. It is currently hosted on my website
• The Pragmatic Programmers have two tools there. First "stakeout", which is written in ObjC using kqueue. It is great because it lets the kernel notify it of file changes which gives the best possible feedback time, but also only runs on Mac OS X. Second "stakeout.rb" is written in Ruby, so it runs everywhere, but its also much simpler and doesn't deal with added or removed files. It runs anywhere though. :)
• Then there is atchange.sh by Jeff Haemer which is written in Perl and is even simpler though.

Of course, keep in mind that there are many more uses for this type of program, besides just TDD you can for example use it to automatically rebuild and display a Markdown or LaTeX file each time you save it.

• Share this:
• Digg
• StumbleUpon
• Facebook
• BuzzUp!
• LinkedIn