Agreed, but I would add there are specific scenarios where doing the test first really helps - when you're building a routine complex enough that you can't think upfront how you'll do it, like a complex calculation for example. In that case, at least thinking about the tests first and making one by one pass helps you breaking down the problem into smaller, easier parts.
This is the best situation for a TDD workflow, and the only situation I myself use TDD in.
If you have complex calculations or data transformations or you know well the expected input and output of what you're trying to do TDD actually speeds you up by allowing you to iterate faster on your solution.
If you're writing glue code between a number of other application components (90% of development in web backends) then TDD loses a lot of benefits.
I think this is the result of code coverage metrics that are often advocated. When you need some arbitrary level of coverage you have to write tests for glue code.
It may be different in dynamic languages, but in statically compiled ones the compiler does all the testing required for glue code.
> In statically compiled ones the compiler does all the testing required for glue code.
It cannot, for example, tell if you have glued things together in the wrong order.
...but a test of the glue code alone will not necessarily tell you that, and you will waste a lot of time mocking the lower-level functions to perform a standalone test on it. It is better to test an assembly as a unit, which will test the glue code (and give you a coverage count for it.) In many cases, it will also test your low-level code without you having to write so many mocks and harnesses.
I think you can find TDD zealots who insist that you have to write tests for every little piece in isolation, but this takes a lot of time, especially if you have to write a lot of mocks to do it (and testing with mocks is error-prone; the mocks may conform to your invalid assumptions.) There is never enough time to test everything, so excessive unit testing means giving up some potentially more informative integration tests. As in most aspects of development, good judgment matters more than strict obeisance to the rules.
