Chapter 2. Unit Tests

After the introductory sections devoted to developers’ testing in general we now move on to the central topic of the book: unit testing.

2.1. What is a Unit Test?

The idea behind unit tests is simple: it is to make sure the class you are working on right now works correctly – to make sure it does its job. This concerns whether, given certain input data, it will respond with a certain expected output, or whether, fed with nonsense data, it will throw an appropriate exception, and so on. The idea, then, is to write tests that will verify this expected behaviour.

But that is not enough. You should test your classes in isolation, and test them to verify that they work in any environment. When writing unit tests it is important to test a single class and nothing more. Forget about databases, Spring configuration files, and external web services. You do not want to include them in your unit tests. Concentrate on the logic of your class. Once you are sure your code works fine, then test its integration with other components! But first conduct unit tests!

Unfortunately, even now many confuse unit tests with other kinds of test (e.g. you can read about "unit testing of your database"), or use this term to describe just any kind of test developers write. Many people claim that every test they write is of the “unit” variety, just on the basis that it is executed by some unit testing framework! Others claim that they are doing “unit testing” and have chosen three layers of software as the unit they are going to test… This is, of course, wrong: it sows confusion and makes discussion difficult. Do not do that! You know what unit tests really are.

Unit tests have some properties which distinguish them from other developers' tests. As discussed in Section 1.2, they are focused on single classes and they strictly control the context in which an SUT is executed. They also run extremely fast and are able to pinpoint bugs with great accuracy, often leading the developer straight to the guilty method, if not to the guilty line of code itself! By giving such precise and immediate feedback on the quality of our work they help us to fix the bugs quickly before they spread through the whole system (see Section 1.4).

The existence of a comprehensive and rigorous set of unit tests allows us to refactor code without any fear of breaking something: once all your classes are covered by unit tests, there are no areas of code left that "no one dares to touch"!

Another benefit of writing unit tests is that they serve as a live (that is, always up-to-date) documentation of our code. They are much more reliable than Javadocs or any other kind of textual description that might be developed in parallel to the creation of the code itself.

Last but not least, a skillful developer can turn the process of creating unit tests into a design activity. This, quite surprisingly, might be the most important of all the benefits conferred by unit tests!

And remember one more thing: unit tests have been brought into this world by developers, and they are our responsibility, our tool and something we take pride in – or, if not done properly, something for us to be ashamed of.

13