Isn't this enough though? The tests gets written, which probably was the main point in the first place?
Which is what most of these mechanism are about: Finding what causes sufficient friction to get the tests written.
(I'm making this comment because I know of a team with a coverage tool tied into CI where the coverage has been ignored for years)
By writing tests early, you make sure the code you are testing is testable and your knowledge about the code is fresh.
IME you also end up writing tests which are far too tied to the implementation. (With the resulting churn that that implies when the implementation changes.)
You get far more mileage from QuickCheck-type tests IME. Granted, not everything is very amenable to testing using QC-type tests, but a lot of stuff is.
I'd rather just trust programmers to consider what approach works best for their problem and mindset and go from there.
I personally don't TDD most things, but it's a tool I have available and I bring it out when a situation arises.
I find it surprising that's not slower than Test-Last (maybe if you really leave it for last then you'll need some time to fit your functions to your test)
> I'd rather just trust programmers to consider what approach works best for their problem and mindset and go from there.
People are often surprisingly good at fooling themselves. I'd rather have actual empirical validation. And also a pony.
Er, no. The studies I've read all end up showing that principled testing helps, but test-first and TDD (strict red/green cycle, code only enough to pass the new test, etc) provide no additional benefit over anything else that gets the tests written.
The "it depends" always comes from the echo chamber trying to justify their desire to believe that TDD isn't completely useless. It actually feels quite similar to the claims I've seen from practitioners that reikei, faith healing, etc aren't complete bunk.