Test-Driven Development
A development practice where you write tests before the implementation, using failing tests to guide your design.
Test-Driven Development (TDD) is a practice where you write a failing test first, then write the minimal code to make it pass, and finally refactor. This cycle is often called Red-Green-Refactor.
The value of TDD goes beyond catching bugs early. When you write tests first, you're forced to think about the interface of your code before the implementation. This naturally leads to cleaner APIs and better separation of concerns. If something is hard to test, it's usually a sign that the design needs work.
TDD works particularly well for domain logic with clearly defined behavior. When you know what the inputs and outputs should look like, starting with a test makes the implementation straightforward. For exploratory code where you're still figuring out the right approach, strict TDD can slow you down. As with every practice, apply it where it makes sense.
One practical benefit that's easy to overlook: TDD gives you confidence that your tests actually verify something. When you see a test fail before making it pass, you know it's not a false positive. Without this step, it's surprisingly easy to write tests that always pass, regardless of whether the code is correct.
References
- 4 practical principles of high-quality database integration tests in Go — Discusses TDD as one of two approaches to gaining confidence in database integration code. Mentions using TDD to start with a test that verifies transaction behavior, and introduces 'test sabotage' as a technique for when not using TDD.
- AMA #1: Clean Architecture, Learning, Event-Driven, Go — Robert and Miłosz discuss TDD in Go, noting it's language-agnostic and that more people could use it. They highlight how TDD helps design better interfaces by forcing you to think about the API before writing the implementation.
- Learning Software Skills fast: what worked for us best in the last 15 years — A listener question mentions studying TDD and BDD as part of learning software development practices, leading to a discussion about application design and modeling.
