« Spellcheckers, prosciutto and cross-site scripting | Main | After The Show, 1988 »

You say 'test first', I hear 'test eventually'

I think there's a common misunderstanding that "test first" doesn't really mean "test FIRST", but something more like "start testing when the code starts doing something interesting", but I think that even that short-cut is more dangerous than one might think.

For example, if you were writing a new class that contains one simple method which takes an array and reports its length, when would you start writing test cases?

  1. Before you write the class.
  2. After you write the class, but before you write the method.
  3. When your method handles a 'null' argument.
  4. When your method starts handling zero-length arrays.
  5. When your method starts handling arrays of length >0.

Purists would go with (1) and answer that since the test fails to compile, your first task would be to make the test compile. Personally I've had the best success with (2). That first test case (which might just be nothing more than an empty test with a valid setup and teardown) might already make you question the very need for the new method or class in the first place.

Based on experience, I think most people practice 4-5.. but I think starting the test writing process at that point is way too late. You've already invested some time in writing some code, and by doing so, have already raised the effort required to start from scratch if your design assumptions are wrong. More effort will be spent retrofitting a wrong assumption at that point than designing as you go.


TrackBack URL for this entry:

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)