Mention “TDD” in Tech-Twitter and you’ll get flooded with:

We love it!
We do it!
It’s awesome!
It’s helpful!

I’m willing to bet, based on experience, that this enthusiasm doesn’t translate in actual usage.

Let me entertain you with some thoughts about this.

First, none of the issues I list here are unsolvable, or deal breakers for everyone every time.

But they are real issues that people like me deal with every day. They make TDD a non-obvious choice and like everything else, force you to understand its trade-offs.

Today, Test-Driven Development (TDD) feels like a select club that only cool kids can access and everyone else feels too dumb to even try.

This is because it’s hard to do TDD properly. This is something that you can’t simply Google and then copy from Stack Overflow.

TDD is a practice that requires —wait for it— a lot of practice. Many years to perfect and get proficient at.

This turns off a lot of people. And the lack of community buy-in makes it even harder to adopt.

And the cycle goes on and on.

Tell me how many people around you are actually doing TDD?

I don’t mean those that say that TDD is great, I mean those that are *actually* practicing it every day.

I’m willing to bet that, for a lot of you, the answer is “not too many”. For most, the answer is “no one.”

Even when you get past that adoption barrier, there’s a lot to dislike about TDD, because —surprise, surprise!— there are always trade-offs.

Fans always talk about how TDD drives the design of your system. This is true. And it’s great!

It is also one of its drawbacks.

TDD will add layer upon layer of indirection and abstraction to your system. This is great when necessary, but dangerous over-engineering when not.

Not every system needs TDD to dictate its design. Not every system benefits from TDD’s byproduct.

TDD is also myopic. It hyper focuses on small units but completely misses the overall picture of your system.

It's good to test small units. It also creates a false sense of security.

Yes, your test coverage may be at 100%, but your system may still be broken.

If you work on a team, y’all do TDD or no one can. There’s no way to push a system forward when some people are just typing code, and others are test-driving the rest.

Remember the buy-in conversation we just had? Yeah, it’ll be hard to find a whole team that believes in it.

There’s more!

TDD requires a significant investment of time. Before, during, and after.

Writing tests for inexistent functionality is not obvious. And it’s a little bit weird.

We can’t just say that TDD is an obvious choice. We need to think first!

So, what’s the conclusion? Should you completely ditch the idea of TDD?

Of course not! I personally love it. I also struggle every day with it.

TDD is not a slam dunk. It’s just another tool focused on delivering confidence in more than one way.

But it’s not obvious. It’s not the only way. If you aren’t doing it, you can still deliver good software.

Heck, I don’t even think you should focus on it until you have a good grasp of another 27 practices that are way more beneficial!

And to finish this rant, remember that automated testing is really important!

(Please, don’t get TDD confused with testing because they aren’t the same.)

You should test. Always. Well, most of the time. When necessary.