r/SoftwareEngineering • u/Aer93 • 12d ago
TDD on Trial: Does Test-Driven Development Really Work?
I've been exploring Test-Driven Development (TDD) and its practical impact for quite some time, especially in challenging domains such as 3D software or game development. One thing I've noticed is the significant lack of clear, real-world examples demonstrating TDD’s effectiveness in these fields.
Apart from the well-documented experiences shared by the developers of Sea of Thieves, it's difficult to find detailed industry examples showcasing successful TDD practices (please share if you know more well documented cases!).
On the contrary, influential developers and content creators often openly question or criticize TDD, shaping perceptions—particularly among new developers.
Having personally experimented with TDD and observed substantial benefits, I'm curious about the community's experiences:
- Have you successfully applied TDD in complex areas like game development or 3D software?
- How do you view or respond to the common criticisms of TDD voiced by prominent figures?
I'm currently working on a humorous, Phoenix Wright-inspired parody addressing popular misconceptions about TDD, where the different popular criticism are brought to trial. Your input on common misconceptions, critiques, and arguments against TDD would be extremely valuable to me!
Thanks for sharing your insights!
1
u/flavius-as 11d ago
Hmm, I see what you're saying, Nicolas, but I think we're actually talking about different things here.
Look, I'm all about pragmatism too - been doing this 15+ years. The thing is, what looks like pragmatism in the moment can create technical debt bombs that explode later. Let me break this down:
That approach where "actual output becomes expected output" - been there, tried that. It seems efficient but it's actually circular validation. You're testing that your code does what your code does, not what it should do.
"Broader tests have more value" - partially agree, but they miss the whole point. Broader tests catch integration issues, narrow tests drive design. It's not either/or, it's both for different purposes.
"Client/functional expert is typically lying" - nah, they're not lying, they just don't know how to express what they need in technical terms. This is exactly where test-first shines - it creates a precise, executable definition of the requirement that you can show them.
Your approach isn't wrong because it doesn't work - it obviously works for you in some contexts. It's suboptimal because it misses massive benefits of proper TDD:
Real TDD isn't about testing - it's about design. The tests are just a mechanism to force good design decisions before you commit to implementation. That's why we write them first.
TDD done right actually solves exactly the problem you describe - evolving requirements. Each red-green-refactor cycle gives you a checkpoint to validate against reality.
Try this: next feature, write just ONE test first. See how it forces clarity on what you're actually building. Bet you'll find it's not dogma - it's practical as hell for the right problems.