Chapter 4: Test Ideas and Heuristics

Overview

So far in this book, we have written unit tests at exactly one point within the software development process: upon realizing a new requirement. However, there are more opportunities to write, modify, or edit tests:

• Once a task is completed, the application code is verified for refactoring possibilities and the test code is verified for quality and sufficient coverage.

• If an error occurs in subsequent development phases—during functional tests or after shipment—we need to write a unit test or expand an existing one to expose the error case before removing the error. This demonstrates that the developers really understood the cause of an error and prevents that same error from sneaking in later. Following this advice will often show that the bug we have just revealed was masking another one and that several unit tests and subsequent code changes are necessary to make the functional test that started it all work.

• Whenever we find inadequacies in test cases, for example, when trying to understand or modify existing code, testing is mandated.

• Testing is appropriate during or after a refactoring of program parts.

The greater experience one has in testing, the more tests will not be found necessary in later stages, but be written when adding new features. The difficulties in creating test cases do not result from a lack of experience, but from fundamental psychological reasons [Weinberg98]. While it is the objective of a tester to find as many defects as possible, developers like to see their software confirmed and may thus overlook errors in their own program that they would see at a glance in other people's code. Faulty programming concepts often lead to the same errors in a test. For this reason, we make efforts to give up the "developer ego" and instead assume the role of a "tester ego" when checking test cases for sufficient coverage (see also Chapter 8). Considering that we will never fully manage this, the cooperation of a second person can increase the quality of test cases considerably, ^[1] either within the scope of pair programming or in a subsequent review.

In the further course of this chapter, we will describe a few heuristics, ideas, and theoretical aspects to improve single unit tests and to find new test cases. As always we have to observe the most important rule: Test code is treated like production code and deserves the same attention with regard to readability and clarity. But we also have to observe another fact: Less optimal tests are better than no tests.

^[1]Sometimes we also have to deal with the requirement to fully separate the test group from the developer group from an organizational perspective to eliminate influences from the psychological phenomenon described here.