Test-Driven Development: Write the Test First

WHY IT EXISTS Traditional development can lead to code that's difficult or impossible to test after the fact. TDD was created to solve this by making testability a primary constraint on design, not an afterthought. It forces you to think about your code's public interface and expected behavior before you write a single line of implementation.

THE MENTAL MODEL Think of TDD as building with a blueprint and a quality inspector at every step. The failing test is the blueprint for the next small piece you need to build. The passing test is the inspector signing off on that piece. The refactoring step is cleaning up the construction site before starting the next piece. This cycle is often called "Red-Green-Refactor".

HOW IT WORKS The process is a tight, repeating loop. First, you write a single, small, automated unit test for a new feature. This test must fail because the feature doesn't exist yet (the "Red" phase). Second, you write the absolute minimum amount of production code required to make that specific test pass (the "Green" phase). Third, with the safety of a passing test, you refactor both the production code and the test code to improve clarity and remove duplication. Then you repeat the cycle with the next small requirement.

WHEN TO USE IT TDD shines when you are building new functionality with well-defined inputs and outputs, like a data parsing utility, a complex business logic engine, or a custom algorithm in Swift. It's also valuable when fixing a bug; you first write a test that reproduces the bug (it will fail), then you write the code to fix it (making the test pass).

WHEN NOT TO USE IT TDD can be less effective for exploratory coding where the final design is unknown, such as rapid prototyping of a UI. It can also be cumbersome for code that is difficult to unit test in isolation, like complex view controller logic or code that relies heavily on external system frameworks. Don't force TDD on a legacy codebase without a clear strategy for introducing tests safely.

ONE CANONICAL EXAMPLE Imagine creating a PasswordValidator struct in Swift. Using TDD, you'd first write a test in XCTest: testPasswordIsTooShort(). You'd assert that validator.isValid("123") is false. This test fails because PasswordValidator doesn't exist. You then create the struct and method with just enough logic to make the test pass (e.g., return password.count >= 8). Now the test is green. Next, you might refactor. Then you'd write a new failing test, testPasswordIsLongEnough(), and repeat the cycle.