|
|
So far in this tutorial, 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 app code is verified for refactoring possibilities and the test code is verified for quality and sufficient coverage.
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 coding 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 ). 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 coding 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.
|
|