<story><title>Is TDD Dead? (2014)</title><url>https://martinfowler.com/articles/is-tdd-dead/</url></story><parent_chain><item><author>DigitalSea</author><text>Sadly, in this day and age of development and the need to constantly ship things, TDD has been dead for a long time. In my 12 year career, I have heard lots of people talk about test-driven development, but I&amp;#x27;ve never seen it in a workplace (at least none I&amp;#x27;ve worked at).&lt;p&gt;On my own personal projects I have dabbled with TDD and I&amp;#x27;ve seen the benefits it can provide, but it does make even simple programming tasks take a lot longer. Sadly, companies these days (especially during the pandemic) can no longer afford the luxury of development taking longer, even if it does mean the end result will most likely be cleaner and have less bugs. The company I work for see shipping potentially buggy code and fixing it as bugs are reported as an acceptable development practice.&lt;p&gt;With the advent of automated builds and deployment processes, it is way too easy to quickly ship code and roll back bad releases or push out emergency patches. Things don&amp;#x27;t have to be perfect the first or second time around. The optics to non-technical executives seeing code go out and features released are a lot better than seeing things take longer to develop.</text></item></parent_chain><comment><author>rzwitserloot</author><text>That should itself be rather telling. TDD is extremely well known, in my experience. I bet if I stuck a microphone under the nose of random passersby at any development convention [1],  90%+ will be able to tell me what &amp;#x27;TDD&amp;#x27; is short for, and even if they don&amp;#x27;t, they&amp;#x27;ll have heard of the concept at least. Hell, I bet most would tell me they &amp;#x27;aspire to do it&amp;#x27;.&lt;p&gt;And yet, more or less nobody does.&lt;p&gt;So either it is next to impossible to begin doing it (seems like a bizarre conclusion), or, perhaps more likely, nobody wants to do it, and the few dev teams that do manage to do this have not managed to turn that into a competitive advantage. Which makes the value of TDD rather questionable based on simple evidence.&lt;p&gt;To explain this observed behaviour that TDD is clearly not a competitive advantage[2], I can name a million pet theories. But without going into any of those, the sheer fact that it&amp;#x27;s __this__ rare in practice says a lot, no?&lt;p&gt;[1] I mostly go to java related ones, maybe it&amp;#x27;s less well known amongst other communities.&lt;p&gt;[2] What other explanation is there? Clearly not &amp;#x27;ah, but, TDD is brand new and you have to give it some time for teams to get familiar with it, and for the concept to percolate through, maybe wait for tooling support to catch up&amp;#x27; - TDD&amp;#x27;s quite an old concept!</text></comment>
<story><title>Is TDD Dead? (2014)</title><url>https://martinfowler.com/articles/is-tdd-dead/</url></story><parent_chain><item><author>DigitalSea</author><text>Sadly, in this day and age of development and the need to constantly ship things, TDD has been dead for a long time. In my 12 year career, I have heard lots of people talk about test-driven development, but I&amp;#x27;ve never seen it in a workplace (at least none I&amp;#x27;ve worked at).&lt;p&gt;On my own personal projects I have dabbled with TDD and I&amp;#x27;ve seen the benefits it can provide, but it does make even simple programming tasks take a lot longer. Sadly, companies these days (especially during the pandemic) can no longer afford the luxury of development taking longer, even if it does mean the end result will most likely be cleaner and have less bugs. The company I work for see shipping potentially buggy code and fixing it as bugs are reported as an acceptable development practice.&lt;p&gt;With the advent of automated builds and deployment processes, it is way too easy to quickly ship code and roll back bad releases or push out emergency patches. Things don&amp;#x27;t have to be perfect the first or second time around. The optics to non-technical executives seeing code go out and features released are a lot better than seeing things take longer to develop.</text></item></parent_chain><comment><author>ceedan</author><text>I treat it like a tool. I use TDD when I encounter a problem that is complex enough that I cannot consider or remember all of the possible inputs&amp;#x2F;outputs during development. Getting all of those dumped into a test is the best way to reduce cognitive load.</text></comment>