4
Test-Driven Development: Let the Tests Be Your Guide
WHAT'S IN THIS CHAPTER?
- How TDD developers let the tests drive the code they develop
- The TDD work flow from requirements to working code
- The three phases of coding a feature in TDD
- How a good test ensures good code
- How to define what “done” is
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, ...
Get Professional Test-Driven Development with C#: Developing Real World Applications with TDD now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.