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:
- Write an automated test that describes the nonexistent feature or bugfix.
- Run and watch it fail.
- Build as much of the feature as you can.
- Run the test again. It may fail for a different reason. Let that drive your next step.
- Repeat 3 & 4 until the test passes.
- Commit your code.
- Refactor (optional, encouraged).
- 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:
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.
What are your thoughts on this? Let me know!
Get better at programming by learning with me! Join my 100+ subscribers receiving weekly ideas, creations, and curated resources from across the world of programming.