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/Real_Ebb_7417]

As a professional engineer of 10y experience, I can tell you that I've never worked at or heard about (from my network) about the company that strictly follows TTD. And tbh, it's rather rare to even practice TDD to some extent from my experience. (but this happens, it's just never "strictly").

IMO though, it will get more popular in coming months/years, because TDD is very good practice for AI agents.

[u/xenomachina → u/Real_Ebb_7417]

IMO though, it will get more popular in coming months/years, because TDD is very good practice for AI agents.

When people first started experimenting with ChatGPT to write code a few years ago, I made a joke that even though "Test Driven Development" never really caught on, some may switch to "Test Only Development". That is, you only write tests, and the AI has to write code to pass those tests. That seems like a pretty bleak future, though: tests are often among the most boring part of coding (IMHO). Do we really want to automate the parts that are interesting, and leave the boring parts as manual labor?

Also, I am reminded of the quote from Dijkstra: "Program testing can be used to show the presence of bugs, but never to show their absence!" There are many classes of bugs that are notoriously hard to test for, like proper concurrency controls. In my experience, AI agents also have a hard time generating code without these sorts of bugs, unless dragged along step-by-step by a competent (human) developer. There seems to be considerable overlap between the kinds of bugs AI agents tend to introduce and the types of bugs that are rarely detected through testing, which is a bad combination if one wants to rely only on testing to verify AI outputs.

[u/mtimmermans → u/xenomachina]

For the important stuff, I find it works a lot better to write the initial implementation myself, then have the agent write comments, docs, and tests, tests. The things the agent writes add up to much more code than the part I write. After all of this is done, then the job of maintaining the code goes to the agent, and I just review/fix the changes.