~pperalta

At the SD East conference a few weeks ago they were giving away stacks of magazines. One of them was Better Software, a magazine dedicated to software quality. One of the articles was “Tapping into Testing Nirvana” by Tod Golding. He writes about his experience with TDD. As many of us that have adopted TDD, he was quite enthusiastic at the beginning, especially as the quality of his software improved. After a while however he noticed that the tests were getting more and more difficult to maintain. As Kent Beck says in Test-Driven Development by Example,

“Test driven development is a way of managing fear during programming.”

That turned out to be the exact opposite of Tod’s experience. He writes,

“Every time I wanted to tweak my code, I found myself worrying about how many tests I’d have to rewrite or simply throw away. I felt like I was continually building and destroying my suite of tests. I expected this at some level, but it still seemed like far too many of my tests were coming and going.”

He comes to the realization that code smells can happen in test code just as easily as production code. For those that are new to TDD, writing a test is simply a means to an end: the working code. Most of the TDD examples that one encounters concentrate on the xUnit testing APIs and techniques (such as mock objects.) However, to realize the full benefit of TDD the test code has to be maintained as much as the production code.

This, of course, led me to the real epiphany. I realized that those extracting the most value from their tests were treating them with much more reverence than me. While I always viewed my tests as shallow, one dimensional dolts that could be thrown away at any second, other developers were treating their tests like first-class citizens.

I am certainly guilty of viewing tests as shallow. My biggest sin in this arena is copy and paste unit testing. When I’m testing a method multiple times with different sets of parameters and conditions, the quick fix is to just copy an existing test method, make a few tweaks and rename the method. This of course makes the test class quite difficult to read and maintain. When changes get made to the production method, all of a sudden a bunch of test methods have to change.

As I looked more closely at their tests, I discovered that the best unit testers were applying all the same values to their unit testing as they were in their own implementation. They were abstracting out concepts, building object hierarchies, leveraging polymorphism, limiting coupling, and so in. In essence, their test code and their application’s code were on equal footing.

This view, in my opinion, represents the next step in TDD. Most people that have been on the JUnit website are familiar with the term “Test Infected”. This is the point where developers realize the immense value of a complete test suite and thus start to write unit tests. Next comes the practice of writing tests before code. Once the tests are being written before code, the next step is to view the unit tests as “first class citizens” and to apply the same concepts of clean code to the suite as to the production code.

Here’s another “me too” congratulatory posting to I21 for the release of Spring 2.0. Keith Donald posted an entry to TSS describing all of the new features. I look forward to trying out the AspectJ integration, the asynchronous TaskExecutor classes, and the custom XML configurations for the bean factory.