TDD의 세 가지 법칙

The red-green-refactor cycle becomes precise through three short rules known as the Three Laws of TDD, formulated by Robert C. Martin. They constrain exactly when you write code.

Law 1: You may not write production code until you have written a failing unit test.

No code is added speculatively. Every line exists to satisfy a test.

Law 2: You may not write more of a unit test than is sufficient to fail. A compilation failure counts as failing.

Law 3: You may not write more production code than is sufficient to pass the currently failing test.

Following Law 2, write only enough test to fail. Here the class does not even exist yet, so it fails to compile.

By Law 3 you write the minimum to pass, even if it looks naive at first.

The three laws lock you into a loop measured in seconds, not minutes: write a bit of failing test, write a bit of code, repeat.

The strictness guarantees every line of production code is covered by a test and keeps you from over-engineering features no test demands.

Because you only write code that a test requires, you naturally avoid YAGNI violations (You Aren't Gonna Need It) and dead code.

The laws feel restrictive at first. With practice the loop becomes muscle memory, producing comprehensive test coverage almost as a side effect.

The laws drive the red and green phases; refactoring still happens once tests pass, with the safety net the laws built.

According to the first law, when may you write production code?

You learned the disciplined core of TDD:

• Law 1: no production code without a failing test
• Law 2: write only enough test to fail
• Law 3: write only enough code to pass
• The laws create a tight loop and full coverage