[ncann]

The only thing that should be said about TDD is that it's incredibly polarizing, one of the most polarizing things in software development in fact. It's incredibly personal, some swear by it, some loathe it. Thus, every TDD introduction should have a big disclaimer up front that hey, maybe this isn't for you and that's totally fine. Just don't be a zealot about it.

[motorest]

> The only thing that should be said about TDD is that it's incredibly polarizing, one of the most polarizing things in software development in fact.

I'm afraid that's not a TDD problem, but a problem created by nitpickers who love petty gatekeeping.

[ikiris]

It’s basically the handwashing for doctors argument over again. Lots of people really hate the idea they could be doing anything wrong and absolutely hate being inconvenienced for something they don’t personally see as necessary no matter how beneficial it might be overall.

[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.

[happytoexplain]

This framing makes sense for well-defined testing in general. Applying it to a specific technique like TDD, however, is exactly the zealousness the parent is talking about.

[yowlingcat]

I think it's lazy and superstitious to make an analogy between practices in hygiene in medicine and software engineering.

But if you want to draw your analogy to its absurd conclusion, I think a lot of people would hate the idea of needing to wash their hands to do a surgery remote controlled by a joystick, because the sterility of the instrument doing the operation is independent of the sterility of the hands remote controlling it from afar.

[ncann]

Doctor hygiene and seatbelt and the like are mandatory because they save lives, and can be very easily proven using basic tests and statistics.

On the other hand, there is no way to measure the "effectiveness" of TDD as compared to not using it.

I'm sorry that you feel that strongly about it but that certainly seems like zealotry to me.