One reason why TDD can be a good idea is the cycle involves actually testing the test cases: if you write the test, run it and see that it fails, then write the code, then run the test again and see that it succeeds, you can have some confidence the test is actually testing something (not necessarily the right thing, but at least something). Wheras if you're writing the test after writing the code and expect that it will succeed the first time you run it, it's quite possible to write a test which doesn't actually test anything and will always succeed. (There are other techniques like mutation testing which may get you a more robust indication that your tests actually depend on the state of your software, but I've rarely seem them used in practice).

Good point. Sometimes I cheat and implement before I test, but often when I do that I'll comment & uncomment the code that actually does the thing so I can see the tests go from red to green.

Have been meaning to try mutation testing as a way of sussing out tests that cover lines but don't actually test behavior.

Snap, me too, amazing how many times it catches a simple mistake too like a < instead of > that you were certain you got the right way round as you wrote it.

This is a great point. You're literally testing the test validity as you go.

Most tests shouldn't be hard to read and reason about so it shouldn't be a problem. In case of more complex tests, you can do it like you would do it during iterative development - debug tests and code to figure out what's wrong - nothing changes here.

It’s funny that in your paragraph there I thought you were about to write… “for that reason alone, TDD is the only way that makes sense to me.”

The reason is, the tests and the code are symbiotic, your tests prove the code works and your code proves the tests are correct. TDD guarantees you always have both of those parts. But granted it is not the only way to get those 2 parts.

You can still throw into the mix times when a bug is present, and it is this symbiotic relationship that helps you find the bug fast, change the test to exercise the newly discovered desired behaviour, see the test go red for the correct reason and then make the code tweak to pass the test (and see all the other tests still pass).

Because the test you've just written (and only that test) fails in the way you expect when you run the suite.

And then passes when you write the code that you think should make it pass. You do catch bugs in the tests, as well as bugs in the implementation!