Chapter 3.5: Mastering TDD and the Red, Green, Refactor flow
Learn the most effective way of building software using TDD by writing tests first. In this chapter we follow the Red, Green, Refactor process to build a simple app.
Disclaimer: You are reading an early version of the text! The final version of the book will be revised and may contain additional content.
Finally, we can start getting our hands dirty with writing code! Let's apply all the knowledge we gathered over the last chapters and put the Perfect Test Setup we've built to good use. In this chapter, we'll create an app using the TDD approach.
Although it might sound counterintuitive at first, the practice of TDD, so creating a test (or specification) first and then writing just enough code to make the test pass is one of the most effective ways of how to build software. A high-quality test produced this way ensures that our software fulfills a given specification at the time of writing the code and even years later after constant rewriting and refactoring of our application. The specifications we write when practicing TDD ensure we can maintain our code base for years.
Practicing TDD and writing tests and specifications before writing the code helps us to improve our code in a couple of ways:
It forces us to think about the public API first before writing any code
Thanks to the test, we get blazing-fast feedback on whether our code works or not
Unit Tests help us to come up with a better architectural design for our application
When we write the test first, we find ourselves in the shoes of a consumer of the code we're going to write. Depending on the type of test, a consumer can be a user of our application or a fellow developer. In the case of Component Tests, the consumer is both a user and a developer. Looking at our application from the perspective of a consumer nudges us in the direction of writing an easy-to-use API and, in the case of Application Tests, can even help unveil UX problems.