Published: September 11, 2019 • Updated: October 04, 2023 • 3 min read
I’ve practiced TDD (Test-Driven-Development) a lot and feel knowledgable about when it’s useful and when it isn’t. In this post, I’d like to summarize what I’ve learned.
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 are distinct. Getting to caught up on terminology can quickly distract from the core concepts they share.
TDD is defined by actions. Here’s my take on classic TDD:
As you can imagine, this is much harder than just writing code. So why bother? Here are my arguments.
You are guaranteed to write a test. Yes, this can be done without TDD, but TDD forces you to do it up front. In some languages this is a big deal.
You’ll get better at writing tests. More test writing, more skill and comfort writing tests.
You can guarantee that it’s possible for your test to fail. This increases the chances that the test is testing the right thing.
You might write simpler code. TDD has a habit of pre-empting clever flourishes and inexplicable extra features. If it’s not in the test, it’s less likely to be in the code (in theory).
You can use the technique to get unstuck. TDD has helped me move past a blank screen many times. You don’t have to know how something works. All you have to know is how you’d like it to work. That can often be a much easier starting point than implementation.
All this said, I don’t use TDD very often. Explaining this using the points above:
Only the last argument— getting unstuck— is where I still occasionally use TDD as a problem-solving tool. And it’s a great tool.
Here are some resources that shaped my understanding of TDD.
There’s writing out there saying TDD is bad, dead, or impossible to do. While I don’t agree, I recommend reading the criticism. Here are two such pieces:
TDD is a technique like whiteboarding: helpful in some situations. Learn how to do TDD correctly, then decide for yourself.
What are your thoughts on this? Let me know!
Join 100+ engineers who subscribe for advice, commentary, and technical deep-dives into the world of software.