Do you believe in TDD?

Last Update: 09.07.2018. By Jens in Developers Life | Learning | Newsletter

TDD here, TDD there.

For many, it is a holy grail.

But is it?

This article I read sheds some light on it. Read it, get your heart pounding, calm down. And tomorrow I’ll stir it up again :-)

Second email in series:

I hope you had a good time reading the article Iand your heart rate dropped to normal again.

Maybe, it didn’t even rise. Like mine.

One thing I love about the internet is that you will find people who think alike or came to the same or similar conclusions. It also always shows me that devs, despite their focus on rational and logic, have the same risk to follow dogmas like any other human too. The difference, however, is that they don’t realize it or don’t want to realize it. But that’s a topic for another day.

TDD puts the unit test as the top priority of a project. Everything should be unit testable. So, as said in the article there is indeed a tendency that the whole system design is under the control of TDD. Not the best design for a particular problem wins, no the design archivable under TDD. This can be the best, but it must not be. Sometimes we can’t even build the best because the problem domain is too unknown or for other various reasons like time constraints.

However, the problem I have is it became a dogma for many devs. TDD is the king and all others are wrong. That’s never the case. Regardless of the topic at hand. And thinking in dogma prevents you from using better-suited solutions.

One thing I learned over the decades of coding, there is never ONE fix for a problem.

Never.

It always depends on the context.

What’s the goal of testing anyways?

To get a 100% bug-free software?

I assume everyone knows that’s impossible. But we want the confidence of being close to that. The confidence to say to the stakeholders, “yes, it works as intended. There won’t be dangerous surprises”.

Can we get that confidence using TDD? Yes. Can we get it with other methods too? Yes.

And that’s where we have to step back and think about our context and which methodic might work for it. How can we archive in our project the confidence that it works and there won’t be many surprises? And then go with your decision, regardless of what the Googlezonsfaceapples do. Your direct peers, the devs working with you, they are your team and they matter. DO what works best for your team and context.