[gregw2]

You seem to be assuming that TDD is only for unit tests in strongly typed /type-extensible languages. I have seen it used for that (Scala) but also used it effectively for even integration tests in languages with limited typing (eg sql stored procedures (!) dealing with large amounts of analytical data)…

When you write the test first, you tend to think through the harder parts of “how do I make this code testable” which otherwise you might shrug your shoulders about and skip — since certain test scenarios may then require too big a refactor which is not worth it.

Just like it’s hard to bolt on security after you’ve built a product, for various system designs it’s hard to build testability if you don’t think about it up front.

The other part of this is psychological; TDD is a psychological trick for task decomposition. Certain people get paralyzed by unknown overwhelming tasks. A failing test case narrows that down to a smaller clearer solvable problem.

Also… cynically, if you write the test first, management (or your inner optimizer… you know you have one!) can’t— when they see you’ve delivered functionality— pressure/tell you to skimp on testing.

I confess I am not convinced the TDD juice is always worth the squeeze, but I have no regrets about the time I spent putting TDD in my toolbelt.