TDD

## RED → GREEN → Refactor The TDD process is extremely simple. First, write a test that describes the expected behavior of the feature you are about to implement. The test will naturally fail (RED). Next, write the minimum amount of code needed to make the test pass (GREEN). Finally, clean up the code without changing its behavior (Refactor). Repeat these three steps in short cycles of a few to several tens of minutes. ## Tests as a Design Tool Viewing TDD as a "testing methodology" misses the point. By writing tests first, the interface of a function—its arguments and return values—is determined before implementation begins. Because the API is designed from the caller's perspective, poorly usable interfaces are less likely to emerge. Kent Beck's motivation for advocating TDD was not to improve test coverage, but to improve design quality. ## Distinguishing TDD from Unit Testing The majority of tests written in TDD are unit tests. However, TDD is a methodology about *when* to write tests, while unit testing is about the *scope* of what to test. Within a TDD cycle, you may write tests equivalent to functional tests, and you can also write unit tests without using TDD. ## Complementary Relationship with ATDD While ATDD verifies the correctness of business requirements from the outside, TDD builds up the correctness of internal implementation from the inside. For an overall project, the ideal is a two-layer structure in which ATDD defines the acceptance criteria, and TDD is used to implement the individual functions that satisfy those criteria.