Unit Testing in Java: How Tests Drive the Code

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...