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

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

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

[mnsc]

Doctors found out that washing their hands caused less people to die, and it's a bit of a nuisance but totally worth it.

Software devs have not found out that anyone dies unless we do strict tdd. But we have found out that unless we have a good amount of automated tests, the software becomes brittle and hard to change.

TDD is more of a style that some swear by that has alleged properties making everything better, like the way doctors wash hands in a peculiar way. But just "washing the hands" thoroughly would probably also help people not dying.

[ikiris]

Therac-25

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

[fzeindl]

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

There are definitely ways to measure, for example by it's impact on bug resolution time. The following study looks at static code quality, but it could be applied to TDD:

This study is about static code quality, but could be applied to TDD as well. https://www.researchgate.net/publication/359129462_Code_Red_...

[gog]

Bug resolution time is not the only metric of value in software development.

[fzeindl]

I quote myself:

> _for example_ by it's impact on bug resolution time