Unit testing is almost a religion but what are the facts? This infographic puts the case for unit testing as simply as possible.

You need to keep in mind that this infographic was prepared by Typemock and hence it isn't exactly unbiased - consider it the case for unit testing prepared by a believer. Even if it only puts the positive side of the argument, you have to admit that there are a lot of positives.

Click for full sized version

Unit testing goes hand in hand with agile programming of all flavors because it builds in tests that allow you to make changes more easily. In other words, unit tests facilitate safe refactoring. The idea is simple: write some extra lines of code that perform tests that verify that a particular block of code - nearly always a function or a method - is behaving properly. You then work on the block until it passes all of the tests. If later on you decide that the block needs to be changed in some way, i.e. refactored, then the tests will indicate at once if you get it wrong. Refactoring without tests is dangerous because you aren't writing "green field" code but changing part of an interacting and working system, and this is much more difficult to get right. It is also claimed that unit tests form a sort of live documentation on what the blocks of code are supposed to do. While this is true, it is a poor level of documentation and not a reason for not write the good stuff.

The big problem with unit testing is that it is more code. And I guess you have to ask the question, who or what tests the unit tests? This isn't a silly question and yet it is one that currently isn't asked much or answered at all. We tend to ignore the simple fact that refactoring often not only disrupts the structure of the program but the structure of the tests as well. In short, unit tests are better than nothing but adding code to test code is not a good way to do it. Most of the criticisms can be fixed but so far the tools that we use are primitive.