Over the last two days I took the opportunity of silence at work to be able to work focused. Since I’m currently reading Growing Object-Oriented Software, Guided by Tests from Steve Freeman and Nat Pryce I tried out their approach while retrofitting some unit tests to some of my test classes.
It took me between one and two hours after lunch to get the first class under test. Implement a unit test, bring in the necessary support code, run the test, make it pass after dealing with some stupidities on my own, then go on. In the end when I felt I was done and couldn’t think of yet another test (I also had checks for exceptions in place by that time), I started a code coverage build to see, which passages of the code I was missing. I got surprised to see that all the tests passed and I had brought in 100% code coverage. 100% line coverage, 100% branch coverage, there wasn’t anything left for the unit testing on that class. Since we also used the class for quite a while I knew it was functioning in our test harness, so I was done with it. I checked in the new unit test and drove home happily. That feeling of pride after polishing up your Technical Debt was a great moment. It felt (and still feels) great.
One thing actually stroke me: My tests were very clear and readable. I was tempted to show them everyone. Since the offices are rather empty during this time of the year, there was no one I could annoy with my pride. I got reminded on Enrique Comba-Riepenhausen on the Software Craftsmanship conference in London in February. He stated during Adewale Oshineyes session, that his customer were on-site to the degree, that they were able to actually read the production code. I felt that I had just a piece of code that my customer would be able to read. (I don’t think so, in retrospection.)
The essence of writing maintainable automated checks lies in writing them clear. Indeed, you should write your test code more clearly than your production code to keep them vital and in shape to serve you during your further development efforts. Unfortunately, teams underestimate the value their test automation brings them when written and maintained properly. There is not much magic about it. But you better take care for your test automation code, or you’ll get trapped in the automation pitfall.
