What is wrong with TDD?

In "What is wrong with TDD?" I answer a question.

You can find questions here:

[ClusterPuppet]

In order to do TDD effectively you have to have a well structured system to start. You have to know exactly what needs to be built and you must have the skills to know how the code is going to look in the end. Once everything is in place, TDD is awesome. But getting there is hard and most of the time not worth it. But I suggest all programmers trying it at least once. Because just like writing testable code, designing a system that makes TDD easy is also a well designed code base.

[sustainableCode]

I think it comes down to preference. I love TDD and do talk about it a lot. Before TDD, my job as an iOS dev was rather dull, frustrating, and ultimately wrong. I couldn't figure out what it's the next thing that could break when I changed the system. i. e. when I fixed a bug or did a new feature.

The real problem came when I decided to start TDD on iOS; I believed few people on iOS use TDD. So I started with a TDD book on iOS. It wasn't the best book on TDD because it felt wrong and slow since I was coupling my tests with the production code and made many mistakes. I never gave up because I knew where I came from, and I knew people like me went through the same problems and thrived using TDD. I just needed to look further until I found them.

Following that, I found great people who had a step-by-step course of doing TDD, but not only TDD, but how to build a great sustainable code that lets you go forward, be in a great functional team, and create Millions of dollars in revenue for the business.

Of course, just like any other skill, it takes time to do it right, just like programming does. Many people see programming as unnatural, just like I did when I started playing soccer at 28, it felt unnatural, and I looked unnatural playing it, too xD. Only Practice makes you better until it feels natural, but you know everyone can either decide to practice and master their craft or not. It's a choice.

[intptointp]

TDD is essentially low-level software design in code.

The analogy is like being a carpenter and penciling in the lines by which you will cut the wood.
You draw out the lines, and as you draw the lines, you notice that the route you envisioned will not work out.

Excellent! Better to notice that as you are drawing than after you started cutting.

I believe we actually all do some sort of informal TDD to some degree.

We write code with the expectation that it will be able to do something, and if it does, then our internal test "goes green" and we move on.

TDD is just the formalizing of this so that every "green test" is sketched out in code and these "lines" are drawn as you go along.

[tongobong]

Quote for fanatics that preach we should use TDD everywhere: "To a man with a hammer, everything looks like a nail"

[brandonking]

Thanks for talking about TDD. I just started trying to use it this week at work since I'm now required to write unit tests.

[someguyOW]

Maybe for normal MIS systems it makes sense since these are generally solved problems.

But when attempting to build an abstraction, I don't see how it would work, given that it is an extremely exploration driven problem.

[genjuroSE]

Well written tests feel like setting specification. Set the spec first then implement the solution, then refactor 👍

[nikolabosnjak]

Hi, Fredrik! What do you think about deno? :)

[mariuscostache]

Hey Fredrik. What do you think about TDD that eventually leads to test-induced design damage? I have in mind the series about "TDD is dead?" with Kent Beck, Martin Fowler and DHH. I personally agree with DHH on this one.

[RH-zkje]

The happy music doesn't really fit your "brutal honesty" style. Death metal, funeral music, or horror-movie soundtracks might be more appropriate...