[pydry]

I swear almost every critique of test driven development boils down to "I wrote a bad test".

Yet TDD has no opinion on how you design your tests. There are people who say "you must do DI if you do TDD" or "TDD must be done with unit tests" and they are wrong but that is a separate conversation.

The author seems to disagree arguing that TDD is "pressuring" him to write tests in a certain way. Bull. He made a choice.

Invariably the shitty test which you write before because you overdid low level unit testing or DI is going to be just as shitty written after the code. Maybe a hint that PEBKAC?

>It’s an intoxicating way to work, especially for someone who struggles with software engineering. It makes you feel like a good programmer

I think somebody needs to get allll the way over themselves.

[voiceofunreason]

> I swear almost every critique of test driven development boils down to "I wrote a bad test".

It does seem that way - this one theme does drown out all of the other criticisms.

That said, (to first order) everyone's been "doing it wrong" for 25 years (give or take, there are lots of reasonable start dates to choose from).

Maybe "everyone" isn't the actually the problem, and we need to be open to alternatives like "our theory of what makes it work isn't very strong yet", "we oversold it", or "it was only ground breaking when compared with just-winging-it".

[pydry]

There are cultural reasons why shitty testing practices have persisted for ~30 years but those practices suck equally badly whether you do them with TDD or without TDD.

TDD is a scapegoat.

[pards]

In my experience, the level of test coverage has little to no correlation to the quality and readability of the codebase.

These are subjective, of course, but some of the easiest codebases to understand had low test coverage, and some of the most complex codebases had high test coverage. The opposite has also been true.

[pards]

For clarity, PEBKAC is "problem exists between keyboard and chair"