Like all ideologies, TDD has holes, and cannot be perfectly applied to the real world.<p>I think the the author is doing what TDD (or BDD) is fundamentally trying to get people to do, by writing such detailed requirements and specs: think about shit before they write the code.<p>When I take the time to properly spec something out down to the interface and calls, implementing it is almost always a cake-walk. If I do TDD to describe the interface, implementing it is almost always a cake-walk. But! I can only do these things if I truly understand the problem and its domain, if I have unknown unknowns my spec and tests will be wrong. C'est la vie.<p>Is TDD a panacea for software development problems? Nope. Does it help? It sure can.<p>Personally, I start writing something using BDD until it's hobbling along (~40% done), and then I switch to TDD for the rest of it since I think it allows me to write correct software faster.
>when the tests all pass, you’re done<p>>Every TDD advocate I have ever met has repeated this verbatim, with the same hollow-eyed conviction.<p>My experience has been much different, in that I've never heard this mantra. I have heard for years 'Red, green, refactor'.<p>I question what it is the author is railing against, as it doesnt seem to be the TDD that I'm familiar with.
I would laugh if it wasn't so crazy that someone that doesn't know how to do TDD was writing an article to say it sucks.
EDIT: after reading the blog post a second time, I even think that the author doesn't know how to write more classical unit-test.
I think TDD is over hyped, it is something many people seem to treat as a silver bullet. That being said I’m not sure if it is fair to say it is fundamentally wrong. As with many “silver bullets” it has its place, I’ve found it particularly useful when I’m writing a complicated function, it forced me to focus on inputs and expected outputs and I code to that specification. With regards to a changing specification, that is a problem regardless of when or who writes the tests, it is a part of life regardless.
<p><pre><code> With this approach I write the tests after the odyssey of
discovery, so the tests are only written to the final design
</code></pre>
Or if your manager tells you there's another DOUBLE SUPER IMPORTANT TOP PRIORITY thing to do, the tests are written <i>never</i>.<p>Strict TDD is a technological solution to a management problem.
This article is so full of bullshit that listing all the wrong things that Chris Fox wrote would make an even longer article. And no, this time I'll not start making such a list because it would be a complete waste of time. This guy is completely ignorant and a very bad developer. Read books before start writing such shit.
Back in 2005, Microsoft published an article about TDD that was wrong. Not just a little bit wrong, completely and utterly wrong. I wrote about it at the time:<p><a href="https://www.jamesshore.com/Blog/Microsoft-Gets-TDD-Completely-Wrong.html" rel="nofollow">https://www.jamesshore.com/Blog/Microsoft-Gets-TDD-Completel...</a><p>The authors of that article described TDD the same way the OP's polemic does: 1) write your tests 2) implement the tests.<p><i>But that's not how TDD works.</i><p>Every complaint the author has stems from this misunderstanding.<p>If you're interested in how TDD and related practices <i>actually</i> work, my talk from last month's Pacific Northwest Software Quality Conference has been getting a lot of praise on Twitter. The whole thing's worth watching, but the TDD-specific part starts at 15:21.<p>Whole video: <a href="https://www.youtube.com/watch?v=_Dv4M39Arec" rel="nofollow">https://www.youtube.com/watch?v=_Dv4M39Arec</a><p>TDD part: <a href="https://youtu.be/_Dv4M39Arec?t=921" rel="nofollow">https://youtu.be/_Dv4M39Arec?t=921</a>
The only reason I like writing tests before code-complete is that I feel less likely to write my tests to the code. But really, that just amounts to defining the functionality of the app beforehand, but by way of unit/system tests rather than some design document.
I think TDD is fundamentally appropriate (and a blessing). I see it as generating proofs for claims that your software does X,Y,Z. This is invaluable to me and has given me confidence in rollouts to production.