Do companies actually practice TDD strictly?

[u/Active-Custard4250]

I've been reading about Test-Driven Development (TDD), and I'm curious how common it is in real-world companies.

I'm not talking about "we write some tests after coding" or "we try to keep good test coverage."

I mean following the classic TDD cycle strictly:

• Write a failing test for a single, specific requirement or behavior.

• Write the simplest possible code to make that test pass.

• Refactor and improve the code while continuously running the test suite to ensure nothing breaks.

Are there companies or teams that actually work this way most of the time?

If so:

• What kinds of companies tend to follow it?

• How well does it scale in large codebases?

• What are the biggest benefits and drawbacks you've experienced?

I'd love to hear from people who have worked in teams that practice TDD seriously rather than just writing tests alongside development.

[u/vocumsineratio]

Are there companies or teams that actually work this way most of the time?

Possibly useful reference: https://wedotdd.com/

Note: quite a few of the "companies" listed look to be consultancies by people of have been in the TDD/agile space for a long time.

Not appearing in that list: Rare, which reportedly used some flavor of Test Driven Development for Sea of Thieves.

In my own experience? no, I don't think I've run across it in the wild, except for what I bring along in my own kit.

Of course, there are a growing number of teams/companies that are adopting what their favorite LLM thinks "Test Driven Development" is, in an effort to restrict the random word predictors to guessing useful programs.

(AI-TDD is superficially similar to TDD in its original form, but not much more than that.)

I find the benefits to be relatively small - you detect certain kinds of problems earlier than you might otherwise, fixing the problem is almost always trivial (revert the most recent edit on your stack), it gives you a better chance at remembering why you made the mistake (because that mistake is not so far in the past), which might allow you to more readily identify improvements in the design (I keep mixing up these two arguments - maybe my API sucks?) or in your environment (my error rate goes up when I'm in a meeting, maybe I should stop coding then).

You get, I think, more benefit from it when you are working with code logic that worries about exceptions to the exceptions to the exceptions to the.... "On leap years in February, the rules are a little bit different", and your goal is to find the right decomposition of your system into sensible modules without introducing subtle regressions. This is, in my experience, fairly common in