Intro to TDD

If one wanted to learn Test-Driven Development, AKA TDD, in 2019, where should they start?

It’s worth mentioning first that there are different versions of TDD. There’s outside-in or black-box TDD, red-green-refactor, BDD, ATDD, and more. They’re all in the same family, but they differ. Each version has a purpose, but they can distract from understanding the core principles they all share.

My Definition

TDD is defined by actions. Here’s my take on classic TDD:

1. Write an automated test that describes the nonexistent feature or bugfix.
2. Run and watch it fail.
3. Build as much of the feature as you can.
4. Run the test again. It may fail for a different reason. Let that drive your next step.
5. Repeat 3 & 4 until the test passes.
6. Commit your code.
7. Refactor (optional, encouraged).
8. Add more tests.

Why Use TDD

TDD is much harder than just writing code. So why bother? Here are my arguments:

• You will write a test. In languages like Ruby this matters a lot.
• You can guarantee that the test failed before implementing the feature. This helps ensure, but doesn’t guarantee, that the test is testing the right thing.
• You can use the technique to get unstuck.

Playlist

Here’s my playlist of resources that shaped my understanding of TDD.

• Test-driven Development - Wikipedia: pretty thorough overview.
• Roman Numerals Kata - Jim Weirich (YouTube): Master Rubyist Jim Weirich live-codes a Ruby programming puzzle using TDD. This is where my concept of naive implementation comes from.
• Exercism: Exercism is an open source project designed to help people get better at algorithms, and all exercises are test-driven. Because it’s initially so counterintuitive, deliberate practice is the key to TDD. This is a great resource to get that practice.
• Test Driven Development: By Example by Kent Beck. I’d be remiss if I didn’t include this book, which is credited with inventing or rediscovering TDD. I’ve never read it.

A caveat: there’s writing out there saying TDD is bad, dead, or impossible to do. Here are a few such counterarguments:

• BDD/TDD Criticized - Elixir Forum
• Problems with TDD - Andrew Dalke Scientific AB
• TDD is dead. Long live testing - DHH

In my opinion, TDD is a technique like whiteboarding or retrospectives: helpful in some situations and a hindrance in others. Learn how to do TDD correctly, then make your own decision.

If I’ve missed a resource you love, please let me know.

Blog of Jake Worth, software engineer in Maine.