Ask HN: If TDD is so great, why is it so uncommon in the industry?

A lot of people and projects that I've been on don't have tests at all, let alone TDD. I always ask about it when coming on-board and people feel like it's something they should do, but there's something holding them back. Either they aren't convinced of the benefit, think it's too much work, have an idea that they can't achieve some level of perfection, or some other belief that keeps them from getting there. IMHO, going from nothing to TDD is a huge jump and I'm often successful just convincing people to do testing whatever way possible. After that, it's a process of waiting for the right moments in time to point out the benefit that the tests gave. e.g. "Holy cow, imagine what this refactoring would have been without tests!". People won't be convinced until they see the benefit themselves. Along with testing, it's good to do PRs so that developers can remind each other to add some tests to build the habit. I feel like just doing tests is a fair compromise and moves a project in the right direction. As far as advocacy goes, I'm neutral on BDD, TDD, or just do tests because there are opinions all over the map on this and I think it's better to get team consensus, rather than alienate people.

TDD is hard to learn and it does ask us to type in more code so the benefit is not immediately obvious.

Most of us do not spend all day just typing in the new code, there is a lot more to it: reading existing code, deciding how new code will fit in, running new code, debugging etc. I've found TDD means I spend less time on all that other stuff.

GeePaw Hill made a nice video where he talks about this as "The Lump Of Coding Fallacy":

https://www.geepawhill.org/2018/04/14/tdd-the-lump-of-coding...

As a form of testing I think there are two main reasons:

1. If we need to push this feature now, some say, reliability and future modifiability only get in the way. Under pressure people tend to focus on mere survival.

2. Developers don't know how to test properly. Namely, they don't know which tests to write and which not. That leads to excess of work, all while many errors (bugs) still find their way into the software. Naturaly, testing seems like a bad investment.

You should have a TDD friendly design before actually use it. But most of the project starts with "let's make a demo to try this idea". And after several years, with thousands of patches applied, the demo finally becomes a product. When new devs join in the team, "the projects even don't have any unit tests, why do we need TDD?"

Unit Tests are accepted as a standard thing in the industry. TDD not so much. Is it great? I don't think so. It does not matter whether you wrote the tests first and then developed the feature, or the other way round. Literally no people manager in my career has mentioned TDD in any sort of setting. In fact the majority have been okay with skipping even writing exhaustive Unit Tests when push came to shove and something needed to be delivered. In the case of statically typed languages, even Unit Tests diminish in value compared to dynamically typed languages: the compiler provides a certain degree of safety that is simply not conferred by the dynamically typed language. A lot of software is written in strongly typed + statically typed languages such as Java and C# by developers who simply do not care about TDD or the software development methodology du jour.

Having worked on teams that do it well, and on teams that don't, it's because people were never taught the right approach. They tend to write bad tests making the experience frustrating.

My opinion: first versions of an app is often written as PoC, without any test. It requires real data (file, db, working external API) and only "works". Because at that time, we (developers) know what should be done and how. Then come users who will define their own stories, where TDD is the best but... it is now hard to test.

> If TDD is so great, why is it so uncommon in the industry?

Likely because it's not actually that great. Every ultra-dogmatic TDD programmer I've met has also generally been weirdly argumentative about literally everything.

I've never met nor heard of a TDD fundamentalist that I looked up to.

memes