Test Driven Development and Getting Things Done

I'm sure someone, somewhere, has already determined this. It's probably been blogged about before, but I just realized something today. Test driven development dovetails nicely with David Allen's time management book Getting Things Done. By creating your tests first, with or without even marking them as TODO tests, builds you a TODO list of sorts for your project.

Other than just being a different way of doing things, I never really took to test driven development for small or personal projects. Most of my projects are web applications and "unit testing" modules never seemed worthwhile because you weren't easily able to test the database and web interactions. Well I can easily say that Perl Testing: A Developer's Notebook by Ian Langworth and chromatic has shown me the way.

I had always focused too much on ensuring that 'make test' would be able to be run from anywhere and simply did not think about the fact that I could automate most of the work of building a test environment and if I wasn't able, to bail on those tests so they would be skipped. For example, you could automate creating your PostgreSQL database, but what if PostgreSQL isn't installed on the server or what about when your user isn't allowed to create databases? You just bail out of those tests.

I was definitely too concerned with getting 100% of the tests to pass 100% of the time, in all possible scenarios now that I think about it.

Comments

Just a quick addition to this, lest new Perlites get confused:

When a prerequisite is absent, what you usually want to do is:

<pre> plan skip_all => "THING not installed";</pre>

That will skip the one file that requires THING be installed. While that probably feels like "bailing out" there is in fact a specific meaning for that term in Perl testing: when you encounter a condition that makes further testing pointless, you:

<pre> BAIL_OUT("Nothing will pass without THING anyway.");</pre>

That stops all further testing in the harness, i.e. "make test" will not continue past this point (assuming you have it set up right). That means other test files that haven't run yet will not be run.

For example, if your module is Foo::Frobinate and it supports frobination in a variety of databases, you probably want to skip_all in the file that tests PostgreSQL frobination if PostgreSQL is not installed. If, however, it's DBD::Pg::Frobinate, you probably want to BAIL_OUT pretty early if PostgreSQL is not installed.

The various conditions under which one ought to not run certain tests can get complicated for people new to unit testing, but once you get the hang of it the payoff is really immense, especially on more complex projects.

More info is of course on CPAN:

http://search.cpan.org/perldoc?Test::...

BTW I got here via Googling for "dbix::class outer join" and stayed to read the notes on hiring. Nice stuff.

Oh yeah, and if you're into GTD or just looking for a turbocharged monster of a TODO list manager, I recommend OmniFocus for Mac and iPhone.

Posted by Frosty on Aug 21, 2008 at 5:03 AM