Having that periodic "TDD: what the fuck happened?" ennui (see also: "Agile", "Lean"). I would have told you, circa a decade ago, that TDD would be a de facto standard by now. It's... not. I wonder why.
Perhaps TDD is not as useful a practice as I (and others of my "generation") think it is. I don't believe this to be true based on my experience, but it is possible.
Perhaps we who have practiced TDD for a long time (~15 or so years in my case) have done a shitty job of conveying its utility and teaching it to others.
I'm interested in outcomes, not dogma, here.
One thing I've noticed is that TDD is (to an inexperienced practitioner especially) sort of anti-self-gratification: You don't even get to write the production code until you write a test. And then you have to refactor before moving on! It's hard.
What is referred as "TDD" by people in my current niche programmer subculture (mostly javascript, a lot of React) is nothing like the practice as I understand it to be commonly accepted by experienced practitioners I know.
Automated testing is not TDD. Writing tests first, alone, is not TDD. TDD does not forbid thinking, talking to other programmers, talking to users, making prototypes or having design meetings.
I don't mind a healthy discussion of the utility/suitability of TDD with anyone, regardless of their experience level. I *do* mind the very loudly voiced opinions about TDD from those who are *not* experienced TDD practitioners.
These less-informed and strongly held beliefs happen to often have amplification from the megaphone of social networking manna.
Not to discount that their lack of knowledge of and experience with TDD is partially the fault of inherent difficulties in learning the practice itself and/or deficiencies in the culture of teaching it on the part of more experienced TDD practitioners.
Often the loudest (and in my opinion, least informed) opinions come from people who are legitimately very good programmers who have contributed to the craft. Someone can be a really good programmer and not have a clue about TDD.
Side thought: Not many programmers become famous by building user applications (as opposed to frameworks), although the vast majority of work done by programmers is on user applications. This could have something to do with it.
Applications often have larger teams of people working together full-time, changing requirements, long-tail maintenance, edge cases, deadlines, that are human-driven, along with the inherent fog-of-war of large groups.
Note: TDD is not about reducing defect count -- at least not directly. It tends to have that effect because, in our infant profession, we associate the word "Test" with detecting bugs. It's possibly a bad name, but it's the one we have.
Many people learn(ed) about automated testing in general and TDD around the same time in their career, so the two are understandably -- and annoyingly, to some of us -- conflated.
I think most experienced TDD practitioners accept that this is a common misconception. Personally, I am only really annoyed by it when a self-proclaimed expert does not understand TDD (which is often) and makes proclamations about its utility (which is often).
There's a dangerous no-true-Scotsman area here, but I think it is reasonable to assert that learning the *practice* of TDD well enough to attain a competent-practitioner level is a years-long practice.
Once the mechanics and thought process is dialed in, the real learning about how to design software can happen. This is lifelong (I hope!)
Though TDD is not easy learn, it is much easier when other practices support learning (pair programming, especially, but also just working with other people). Many modern workplaces do not make learning a centerpiece of their business and tend toward solo work.
Without falling totally into get-off-my-lawn mode, I think that there are many who have not taken on that practice, and who don't yet understand what they don't understand.
Perhaps part of it is the explosive growth of our field (a good thing!) and the resulting skew toward the average developer having less experience -- also the perverse economic incentives that move people out of programming jobs as they age.
The person with five years in the industry probably *is* a Senior Engineer, statistically, within their org. Also who gives a shit about titles? (answer: recruiters... but that's a topic for another screed)
Anyway, I am a bit surprised that TDD is so misunderstood and scarcely practiced, especially now that tooling, libraries and languages are so much more amenable to it than back in the early 2000s. I don't have any answers here.
