Why Unit Test?

Unit testing is one of those things that it's easy to live without - before you've lived with it. A programmer that I've known in passing for many years who writes C# code for a medium-sized database software company recently told me that they have no unit testing at all for their main line product.

I was shocked. Of course this programmer had wanted to do this for a while, and had even had another junior programmer assigned to the task for a short time, before he got taken off to do some other "more important" part of the project. Uh ho.

Well, I wish I had some figures to give you, since I'm sure they would be quite revealing, but lacking that I'll have to get by with just a bit of logic:

How much time do you spend debugging code v.s. writing it? Especially as your project grows. As it grows it gets worse and worse, even the smallest changes require significant debugging, because of the effects that they have on all of the other parts of the system.

This is where unit testing shines. Most people who don't unit test claim that the testing itself takes too much time. And, at the beginning of a project, this is true. But what this viewpoint fails to consider is that as the project grows so does the potential for introducing bugs - simply beacuse there's more code running. And after you've written several thousand lines of code or so, the tide starts to turn, and all of the little bugs start to crop their little heads up - the bugs that would have been handled by unit testing.

So I'd say one of the key factors to consider when looking at how much unit testing should be involved in a project is the project's size/lifespan. If it's fairly complicated, and is going to be around for a bit - you definitely want to unit test.