I’ve always been highly skeptical of this approach. Often what you’re doing is so clear cut that tests are entirely unneeded. In fact, outside of the most compl

I’ve always been highly skeptical of this approach. Often what you’re doing is so clear cut that tests are entirely unneeded. In fact, outside of the most complicated cases, I don’t even use unit tests. I have black box testing that I use to check for regression. My biggest reasoning for this is that test code is effectively another code base to maintain, and as soon as you start changing something it’s legacy code to maintain. All that being said, I haven’t spent much time on teams with a particularly large group of people working in one project. I think the most has been 4 in one service. The more people working in a code base, the more utility you get from TDD, I believe. It’s just tough to have a solid grasp on everything when it changes rapidly.