2004-05-28
Test Driven or Test First coding
I don't think that I've ever made a distinction between Test Driven coding and Test First coding, as PragDave does. Dave's description of the two makes sense to me, but perhaps not all the way.
In test-first, you never write a line of production code until you first have a failing test that will be "fixed" by the code you write. Want to write a new class? First write a test that instantiates it, watch the test fail, and then implement the class body to fix the broken test.
This could be interpreted in two ways. The tough interpretation says that if you want to create a class named Firecracker you first add a test (not necessarily a test case) that tests instantiation of the test class. In java that could be something like this.
public void testFirecracker() {
assertNotNull(new Firecracker());
}
This seems too rigorous to me. I did this back when I first started playing with UnitTests. I even went further and created unique test case classes for each class added, but nowadays my interpretation is looser; it takes so much time and effort to create and, most of all, maintain all these tests.
The maintainance required is actually what bothers me the most. I feel that you're much more locked into a particular design when working this way. Instead I interpret the Unit in Unit Testing as something above the class. The tests in my test cases today tries to express the inteded usage and functionallity of a specific class or a set of classes. I add a lot of code around the class being tested—other classes, C-functions, whatever needed to make the tests run—and my reasoning is that my tests will eventually be expressive enough to catch (almost) all possible errors. And, I'm always writing the tests first so I do consider myself a test first coder, from time to time.
I don't think this interpretation of mine is in conflict with PragDave's definition of test first programming. I do write a test that tests instantiation of a specific class, but indirectly. In my opinion, the instantiation test doesn't even have to utilize the class in question to fullfill the test first requirement; the effects of the indirectly used class are covered in the test. I'm not sure if this is what he meant though.
