WHAT'S IN THIS CHAPTER?
As mentioned in Chapter 3, the aspect of TDD that developers seem to struggle with most is the idea that you should use tests to drive your initial development. For years developers have thought of tests as a way to validate their code when it was complete and ready for delivery. Tests were used in a work flow that took a set of requirements, turned those requirements into working code, and then verified the code using tests.
The problem with this paradigm is that it delays testing until the end of the process. Even the smallest application will have some defects. Without tests you lose the ability to quickly and easily determine where in the code the defect is occurring. It also becomes very difficult to design and write unit tests around existing code, because testability probably was not a priority when the code was written. Refactoring is difficult, because you have no quick and easy way to verify that your refactored code still works the way you intended.
The easiest way to solve this problem is to turn the entire process upside down. In this chapter you will see how writing tests, based on the business requirements of your application before the first line of code is written, ...