Test Driven Development.

[Daniel Pitts]

So, my work brought in Joshua Kerievsky, author of Refactorying to Patterns, for a workshop on test driven development. I think its a very interesting idea, and I'm attempting to use it in my Jatra project (Java port of AT-Robots)

The basic concept is that you write microtests (a.k.a. unit tests). This is nothing new, but what's new is when/how you write the tests.

Most important, the tests should have specific output. Did it work, or why i didn't. You don't want to have to read the output and make sure it looks right. You want to know its right just because it said nothing was wrong.

So, the first then you do is decide on one small feature you want to implement, and write a test for that feature. An example feature in AT-Robots would be "When the CMP instruction is executed, the flags should end of set appropriately".

So, you write the test, and the minimum amount of code so that the test compiles.

You run the test, and see it FAIL. It is important at this stage that the test fail, since you haven't implemented any behavior yet. If it passes, that means that your test isn't actually checking for anything useful.

The next thing you do is implement that feature. Don't worry about great design; design comes later. You know you've implemented the feature when all of the tests pass. Its important that all of the tests pass, so you know that your new feature didn't break existing features.

Now is the time to worry about design. You have a new feature, and it works. You have a test for all your existing features, so you can tell if you break something on accident while fixing the design. You can now use a technique that's been termed Refactoring. Refactoring is a course in its own right, but basically its different ways of reorganizing your code, while maintaining the same observable behavior.

Refactoring is what gives you the good design you need to be able to add new features. And you start the process again by deciding on the next new feature.

It sounds like a tedious process, but it helps produce much higher quality code, far fewer bugs, and its a lot easier to come back and alter/create behavior later on.