You can also add a coverage tool to your CI and get the same result (tests get written) without any of the ideology (TDD fairies sprinkle unicorn dust everywhere).

That assumes you are disciplined enough to act on the result.

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)

Coverage tools are not sufficient for getting good test coverage. One can easily make code 'covered' without having proper tests for them.

By writing tests early, you make sure the code you are testing is testable and your knowledge about the code is fresh.

> 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've heard that tests written specifically to drive up coverage metrics aren't much better than no tests.