[ta_1138]

No it's not. I worked at places with mandatory TDD and pair programming for years. 100% coverage or nothing, so it's not as if I have not seen what the advantages can be. But doing that kind of work also makes it trivially easy to see the tradoffs.

There are areas at the edges where the mocking/stubbing required to really follow TDD cause make changes harder but never find bugs. There are entire families of bugs that are far better handled via strong types than by building tests. In the right languages, there's functionality where some kinds of tests are just testing the library, but hard red-green-refactor mandates tests with negative value. We all have been in situations where a small code change requires 6 hours of changing tests for reasons that weren't tied to the real reason the test was there, but ancillary reasons. There are tradeoffs.

When someone asks me whether we should use TDD on a project, the right answer depends on what it is, which language it's written, and whether we are mandating it across the entire codebase, or there are specific things where we will ignore the worst cases. Are we writing payment software in Ruby? a data pipeline in Haskell? Making a bunch of API calls in Clojure? It's not all the same.

[hitchstory]

>There are areas at the edges where the mocking/stubbing required to really follow TDD cause make changes harder but never find bugs

That's not TDD that's either a badly designed unit test or (more likely) you should have written an integration/e2e test instead.

>There are entire families of bugs that are far better handled via strong types than by building tests.

Tests and types are not solving the same problem and they work better in conjunction than alone. Types reduce the execution space, reducing what can go wrong and tests validate the execution space that does exist.

Yes, types reduce the need for tests by shrinking the execution space but this will be for scenarios which should never happen.

There are entire families of code and bugs that unit tests are unsuitable for but that's a whole different topic.

> but hard red-green-refactor mandates tests with negative value.

I have never seen an example of this. I've seen plenty of tests with negative value but they were simply bad tests - usually a unit test when an integration test was more appropriate.