The beauty of unit tests

Small confession, I only started writing unit tests a couple of years ago, but since then I find myself becoming more and more obsessed with unit tests. The development manager at the company I am currently contracted to has called me a “unit test evangelist”. Why have I become so fanatical in such a short period of time? I guess being interested in the whole development cycle I can see the huge benefits of code that has been properly unit tested. I’d like to list what I see as some of the advantages, in no particular order, and certainly not exhaustive.

- coverage: it is important that whenever a piece of code is written that the underlying logic is tested as soon as possible, and in isolation from the rest of the system.
- Confidence: If a class has been adequately unit tested, then anyone using that class can have a certain level of confidence in using that class.
- Demonstration: When the writer of a class writes unit tests against that class, the unit tests can be used by another developer to understand how the class is supposed (and not supposed in the case of negative unit tests) to be used.
- Shorter System Test: As I’ve mentioned before, the system test phase of the development cycle is the most unpredictable phase of the entire development cycle. If bugs are found by the developer in unit tests, they will never make it to system test.
- Refactoring: in todays “agile” world, refactoring is how a lot of companies enhance their software, but it can lead to bugs if the existing system is not understood properly. If a project has adequate unit test coverage, then any false assumptions made by the developer refactoring will be picked up immediately by the unit tests and will force the developer to understand that bit of the system before continuing.
- Performance analysis: A good set of unit tests can be used as a starting point for performance profiling. I have actually heard of one company that had the tradition that every Friday, all developers would stop what they were doing and concentrate all their efforts on improving the performance of their five slowest unit tests. Even if you don’t do this, you can at least see where your performance problems may lie.

I hear a lot of developers complaining that it’s too much effort to set everything up to a point where their classes can be unit tested. It can be a bit of an effort in some cases if say you’re working with data layer classes that talk to a database, however, it just requires a bit of thought when you start the project, and a lot of the setup work can potentially be re-used in the main application. I have yet to see any case where putting in the extra effort has not paid off. The only exception I can really think of is that retro-fitting unit tests to a piece of existing software can be more pain than it’s worth, however, this shouldn’t be an excuse not to start. My recommendation would be to make the decision that any new piece of functionality should be fully unit tested.

What I would like to do is over the course of the next few weeks I’ll write up a few articles about getting started with unit tests, and focus on a few different options available. If you have already been convinced by more most eloquent argument and want to get started right away, then here are some links to see you on your way.

For .Net developers, there is nunit.
For Java developers there is JUnit, and
For C++ developers, there is C++ Unit
There is even a TSQLUnit for unit testing your Transact SQL.