The Spec
The Language
The Practice
The Books

When Not to Test First Revisited

Really, there is never a time not to test first.

I am going to have to admit that I was wrong. In an earlier article I argued that there was a time to avoid testing first. My argument for this idea was that declarative code doesn't need to be tested but imperative code does. My argument was based on the concept that testing declarative code is sometimes no more than merely repeating the same assertion in a test that was asserted already in the code.

This concept deceived me in my effort to find a faster way to code and compete with my non-testing peers. I have to say that I believe that I was wrong and here's why:

The test copy of the assertion has a different purpose than the code has.

The code is intended to provide some kind of behavior that, without it, doesn't exist. The test code is there to provide a way to verify that the behavior of the system is correct. The fact of the matter is, declarative code is sometimes so easy to test that all you have to do is to verify that it exists in order to verify that the behavior will be there. Perhaps this is because a tool vendor didn't provide an easy way to emulate the behavior for testing purposes, but did provide a rich declarative language by which to operate the tool.

Another point I made was that both the test and the production code produced duplication. I believe that this is also in error. At this point, I am more apt to believe that the only reason that the test code and the production code are duplication is because I failed to delineate the difference between the two assertions by using appropriate names. One should clearly declare the desired structure, and the other should be checking that the behavior that the structure creates exists. If the only thing we can do is to check the same code, that is ok because the two will be used at different times and for different purposes.

One of the things I like about writing on the web as opposed to printing books is that I am able to make changes as I learn. This is definitely one of those times. Don't be surprised if I argue with myself. I hope that you will experiment with these things and come to your own conclusions.

So, when should you not test first? Now I say "Never. You should always test first."

Troy Taft is the Principal Consultant and founder of Troy Taft Consulting, a firm specializing in high value software development. He also authors a free monthly newsletter called Software Matters.

Copyright 2007 Troy Taft All rights reserved, you may print this article for your personal use.