Right now I’m make a push at work to increase the percentage code coverage by our unit tests. Let’s just say that the numbers are very very low. But they are increasing. This morning as I was lying in bed I was wondering why I was fronting this initiative. I certainly have no qualms about making this push, but I’m trying to figure out all the reasons why. In the end I figured I would just put my thoughts down here.

Last winter I spent a bunch of time working as a maintenance/support programmer on this application and one thing became clear to me. When I went into the code I was never confident that the changes that I was making weren’t breaking something larger than what I was working with. This was very nerve racking as I was regularly making hot fixes to the application and when fixing a bug the last thing you want to do is introduce a new problem. I know that writing tests will not prevent this from happening, but I would have like the comfort level that a well written test provides.

One of the most tried and true ways for developers to test their code is to try different scenarios in the belief that these manual tests will cover all possibilities. No matter how good a programmer or manual tester you are, there is no way that you can test and then state with certainty that you’ve covered all situations. For the lines that you didn’t know that you didn’t run, you have potential time bombs. Instead of risking these situations, I’d rather write tests and then strive to getting code coverage that nears 100%. The closer to 100% that I can get, the more likely I have eliminated all erroneous code.

The third reason that I’m making this push is non-coding. As your software grows and the complexity of its functionality increases you will begin to exert more and more pressure on your test team. While unit testing is not a replacement for real people testing, it can be used to relieve some pressure from them. If you know that you only touched some logic in a specific business function and that code is still passing all the tests, you probably can get away with a less vigorous manual test regime.

The last reason that I’m an advocate of having tests created is that they work as specifications embedded in the code base. You can look at a unit test(s) for a specific function and know exactly how that function is supposed to work. If you have no unit test to provide this information to you, you will have to search through the code in the function and hope it is correct, and that you read it correct, to determine how the code is functioning. Worse yet you will have to spend countless hours digging through design docs, change requests and other supporting documentation so that you can piece together the most recently signed off functionality for that part of the system. Having done this myself, you can trust me that it is not any fun.

Overall the spirit of testing is to provide a quick and consistently repeatable batch of code level tests that can aid in the verification of system functionality. Having tests provides another level of business knowledge to the developer, and it’s in an environment that they are comfortable with. On top of all of this, unit tests can help, but don’t guarantee, with increasing the quality of the code that your team turns out.

I’m the Igloo Coder and today I’m hot….hot and bothered….so quit pissing me off.