We managed to finish our Tic-Tac-Toe game using the Red-Green-Refactor process. The examples themselves were simple and you probably didn't have a problem following them.

The objective of this chapter was not to dive into something complicated (that comes later), but to get into the habit of using the short and repetitive cycle called Red-Green-Refactor.

We learned that the easiest way to develop something is by splitting it into very small chunks. The design was emerging from tests instead of using a big upfront approach. No line of the implementation code was written without writing a test first and seeing it fail. By confirming that the last test fails, we are confirming that it is valid (it's easy to make a mistake and write a test that is always successful) and the feature we are about to implement does not exist. After the test failed, we wrote the implementation of that test. While writing the implementation, we tried to make it a minimal one with the objective being to make the test pass, not to make the solution final. We repeated this process until we felt that there was a need to refactor the code. Refactoring did not introduce any new functionality (we did not change what the application does), but made the code more optimal and easier to read and maintain.

In the next chapter, we'll elaborate in more detail about what constitutes a unit within the context of TDD and how to approach the creation of tests based on those units.