Lately I’ve been adding unit tests around a critical subsystem of the application I am working on. Luckily I had some downtime to add unit tests to cover parts of the subsystem that I did not develop (of course with TDD all of my new code was covered!). Here are some tips I’ve learned in the process.

Since the parts that lacked a test harness (my term for a set of unit tests) had been used in testing for a while, I didn’t try to figure out what each method was supposed to do exactly. I put unit tests around the class and method that reflect the current result. That way I could refactor without fear, knowing that I had not changed any of the current behavior. If parts were later found to be incorrect, I could quickly make the change in the unit test, which would then guide my bug fix coding. I consider the ability to make a change quickly if something is wrong more important than implementing fewer unit tests that were right (at the time, since we all know requirements change).

When figuring out where to add unit tests, a code coverage tool is invaluable. I frequently used NCover and a custom application that used XPath queries to select only the code coverage reports I was interested in. My subsystem was not a separate application, and it crossed several logical layers. Initially I would target those classes with no unit test coverage (there were plenty, trust me!). After that I could find untested code within otherwise well-tested methods that might be causing a problem. I did not always write a unit test, as 100 percent test coverage was not the goal. The goal was to improve the test coverage in important areas, not to exercise every unlikely error condition. If it happens later, then I’ll add it!

Management, of course, wasn’t very interested in me working without creating new functionality. So I had to create some numbers to measure what I was doing. I started with a count of the lines of code for the entire project and my subsystem, with added emphasis that my subsystem was critical to the application’s success. I also included the number of unit tests, both total and for my subsystem. In management’s view, as long as this number increases, it doesn’t matter if you refactor your tests internally. Finally I added code coverage as a percent of each logical tier and as an overall number for my subsystem. The display looked something like the following (numbers are fictional):

• Lines of code
• Total: 200,000
• Subsystem: 75,000
• Unit test code coverage (subsystem only)
• Services: 72.33%
• Data: 37.45%
• Overall: 61.17%
• Automated unit tests:
• Total: 580
• Subsystem: 490

I also gave reports on how many classes were added and removed, the reduction in the number of lines of code from removing duplicate code, and the number of bugs found. It also helps to bring up any incidents where the unit tests discovered a subtle bug immediately, rather than letting QA pick it up. Some of my refactoring was also to improve performance, and a simple before/after snapshot works wonders. With all this data I was able to convince management that the refactoring work was important.