4.10 Summary

This chapter concentrated on clues and theoretical basics to explain how you can improve and expand your existing test cases and how you find missing ones. Focusing on individual tests, improvements in test method naming, length, and simplicity were suggested. Test cases should concentrate on the typical usage of the CUT, on threshold values, and on equivalence classes. Error cases are equally important to test and the interaction of several objects must not be neglected. Moreover, the ideas in design by contract can give valuable hints for certain kinds of tests. Last but not least, one should never forget to adapt the test suite during and after refactoring; this can induce considerable but worthwhile effort.

I intentionally did not discuss the algorithmic and formal implementation of various software models in test cases—an aspect frequently discussed in the test literature. My reason was twofold: First, there are very few up-front models available in the course of test-first development. Second, the methods suggested there usually generate an overwhelming number of different test cases. This has a deterrent effect on "normal" software developers, and it also omits the meaningful balancing between testing costs and benefits.^[13] In addition, although formal test case generation methods theoretically achieve a larger code coverage, their drawback is that they can hinder intuitive testing. Effective testing derives from intuition; restrictive rules hinder the intuition. Nevertheless, those who reach the limits of the test ideas described here, or those who are simply curious, will hopefully find more help in Bibliography and List of References, Further Reading.

^[13][URL:TestingAgile] is all about finding the balance between no testing and complete testing given the needs of different kinds of software.