17.1. More Tests Mean Better CodeWhy should we test during development? The short answer is that we find out about problems sooner and tests force us to program in much smaller chunks (since they are easier to test), which is generally good programming practice. Although we may think we have extra work to do, that's only short-term overhead. We win down the line when we spend less time debugging, both because we've fixed most of the problems before they were problems and because the tests usually point us right at the problem we need to fix. Along with that, we'll find that it's psychologically easier to modify code because the tests will tell us if we broke something. When we talk to our boss or coworkers, we'll also have the confidence in our code to answer their queries and questions. The tests tell us how healthy our code is. Different people have different ideas about testing. One school of thought, known as Test-Driven Development , says that we should write the tests before we write the code that is being tested. On the first go-around, the test fails. What good is the test if it doesn't fail when it should? Once we know it fails, we write the code to make it work. When that works, we write a test for another feature, repeat the process, and keep doing that until we're done. Along the way, we've verified the functionality and features. We're never really done, though. Even when the module ships, we shouldn't abandon the test suite! Unless we code the mythical "bug-free module," our users will send us bug reports. We can turn each report into a test case.[*] While fixing the bug, the remaining tests prevent our code from regressing to a less functional version of the codehence the name regression testing .
Then there are always the future releases to think about. When we want to add new features, we start by adding tests.[
|
]