Chapter 6. Lie to me: Reliability through testing
This chapter covers
- Designing a suite of unit tests
- Applying input coverage criteria
- Measuring code coverage
- Assessing and improving code testability
Even developers who’ve never heard of design by contract know what tests are: the final phase of every software development project, when evil people called testers try to expose your brilliant time-saving hacks and characterize them as “bugs.” Jokes aside, tests have an increasingly central role in the modern software development process. One well-known point of view, called test-driven development, even suggests that tests should come before, rather than after, any production code. In that case, tests are used as executable specifications, and the rest of the system is written to pass those tests.[1]
1 You can learn about TDD from the book Growing Object-Oriented Software, Guided by Tests, mentioned in the Further reading section at the end of this chapter.
The content of this chapter is independent of the specific view you hold on tests. You’re just going to enrich Reference (or any implementation that conforms to its API) with a set of tests that’s reasonable and tries to cover its functionalities as much as possible. In line with the theme of this book, I’ll focus on unit testing, that is, testing of a single class. Later, I’ll critically analyze the water container API in the light of testability and suggest some improvements based on common best practices.