Unit Testing

Yesterday I made a presentation on JUnit and unit testing in general. I tried to make my presentation very informative, but it's really a pretty interesting topic. I think unit testing is one of the most misunderstood aspects of software engineering.

Most engineers resist the idea at first, and for good reason. It seems like a lot of overhead being added to the development process, and it's usually overhead that nobody is going to give them time for. I know that's the way it seemed to me when I was first introduced to unit testing. I started to change my mind on the subject because I was able to experiment with it first. Having a structured but easy-to-use framework for testing my code as a I developed it was great. As I became more and more familiar with it, and had the chance to teach others about it, I became more in-tune with the philosophies behind it and more rigorous in my approach.

I really became cognizant of the misconceptions about unit testing while I was working at KeepMedia. On one hand I had a manager who did not like the idea of introducing overhead, just as I had felt years before. On the other hand, we had a very understaffed QA staff, and they looked at developer written unit tests as a way to get quality building blocks for regression testing. Of course there are flaws with both of these mindsets.

Unit testing is overhead, but not necesarrily significant overhead if you use a framework like JUnit. Of course the more complex an application is, the more effort there will be in creating sufficient unit tests. A complex application needs more unit tests, though, and that's the point. Unit tests don't add as much overhead as you think because they help you catch a lot of bugs early on. So the extra time you spend early on writing unit tests will translate into less time later. It can also translate into less time during the QA cycle, which is a bonus since there are more people's time involved at that stage. The hard thing for inexperienced engineers and managers to understand is that bugs will happen, and that's what makes unit testing valuable (well there's other things too, but I won't get into that yet.) My manager at KeepMedia was inexperienced in managing software engineers, so this was not easy for him to understand.

Now I mentioned the QA cycle above and how unit testing can reduce that cycle in many cases. However, unit testing is not meant for QA, it is meant for developers. Of course functional testing by QA has a lot in common with unit testing, but QA should never use unit tests written by developers as a substitute for their own functional testing. JUnit (especially with Ant) makes the aggregating and automated running of unit tests very easy, and it can be tempting to leverage this for regression testing. This is an equally bad idea. I was actually surprised that QA people would want to do this, since you would think that they would see that such an approach would eventually eliminate a company's need for QA at all. If developers write all the unit tests that you need to perform functional and regression testing, then why do you need QA? Many XP pundits would actually say that you don't, but I think QA is still very valuable. I think they are valuable because of their objectivity, but you really lose that if they make use of unit tests written by developers.