A distinction exists between test-first programming and test-driven development. The former is an easy practice to convey whereas the latter is a hard discipline to learn. Test-first is, however, a stepping stone that helps you get to test-driven development.
TDD is more than just getting good specifications in place that happen to be tests. It is also more than just getting good tests in place that happen to be specifications. It is about building executable specifications. That is, it is about creating documents that are both tests and specifications to such a degree of quality that you don’t need any other documents to do either of those jobs.
Test-driven development has a lot more to it, but this chapter should give you the context you need to get started. Throughout the remainder of the book, remember these things: Try to specify behaviors in tests before implementing them, and grow your designs inward from the point at which a test couples to what it tests.
The next step is to put in place structures that allow you to change your designs with great confidence, especially with regard to the safety of production data.