You don’t understand TDD yet.
It’s not as rare as you think: see
Dave Schinkel

Sorry — don’t buy this claim.

Tell me explicitly what of TDD I am misunderstanding if you believe that to be the case.

I have attempted to use your methodology. What I find is that I end up with too many tests of parts that, in hindsight, are obviously correct. I find I spend too much time in early phases refactoring sludgy, boring unit tests that never fail and never will fail.

Test that never fail at any time are pointless and not a good use of my time.

And overall, people don’t pay me for tests but solid features.

I personally feel that my style of test creation — where some parts get cursory testing because the code that implements them are obviously correct and other parts get obsessive, every-possible-case testing because the code that implements them is trying — is an optimal use of my time.

I have yet to see any decent practical argument as to why doing the tests first is better. You’d do better presenting me with such argument than chiding me because I haven’t used your academic, formalist methodology, when I have and decided that it was silly.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.