Hack 63. Run Tests Automatically

See what's broken right after you break it!

The idea behind test-driven development is that rapid feedback based on comprehensive test coverage helps you write sane, clean code that never regresses. Once you know how to write tests, the next step is getting sufficient feedback as soon as possible.

What if you could run your tests immediately after you write a file? That's fast feedback that can help you see if you've broken anything. Best of all, you don't have to switch from your most beloved editor!

The Hack

The heart of this hack is the onchange program:

#!/usr/bin/perl # onchange file1 file2 ... fileN command use strict; use warnings; use File::Find; use Digest::MD5; my $Command     = pop @ARGV; my $Files       = [@ARGV]; my $Last_digest = ''; sub has_changed {     my $files = shift;     my $ctx   = Digest::MD5->new( );     find( sub { $ctx->add( $File::Find::name, ( stat($_) )[9] ) },         grep { -e $_ } @$files );     my $digest      = $ctx->digest( );     my $has_changed = $digest ne $Last_digest;     $Last_digest    = $digest;     return $has_changed; } while (1) {     system( $Command ) if has_changed( $Files );     sleep 1; }

This takes a list of files or directories to monitor and a command to run when they change. Of course, using File::Find means that this processes directories recursively.

Running the Hack

For a Perl application that uses the standard CPAN module structure (modules in lib/, tests in t/, and either a Makefile.PL or Build.PL to control everything), running is easy. Open a new terminal, change to your build directory, and run the command:

$ onchange Build.PL lib t 'clear; ./Build test'             

Then every time either a test or a module file changes such that its MD5 signature changes, onchange will rebuild the project and run its tests again.

Hacking the Hack

MD5 signatures aren't the best way to tell if a file has changed. Even changing whitespace can make files look different (though sometimes it can be significant). You could use PPI::Signature, at least on pure-Perl code, to examine files and see if there are any syntactically significant changes.

You don't have to run all of the tests every time a module changes; it might be sufficient to run the user tests and the module-specific unit testsbut onchange needs to change to make this happen. If you had some way of correlating module files to their tests, you could even do this automatically.