The #1 benefit of a TDD is - Identify bugs earlier. Nobody wants to ship bugs to a customer. This is much more beneficial when we have larger dev teams. And add

The #1 benefit of a TDD is - Identify bugs earlier. Nobody wants to ship bugs to a customer. This is much more beneficial when we have larger dev teams. And add CI that runs tests and reports build/test errors. Overall the team becomes more efficient too. However, I have found that much of the TDD approach needs to be tweaked to the requirements. TDD can become a huge overhead - and overheads don't get maintained. For example, when writing an API service - the endpoints are important and expected to work correctly. Yeah we need to test those specs with tests. But the API endpoint might call 10 different methods within the code. But TDD will mention each method should be tested - this is where the overhead begins. And then people are very opinionated about how to define a unit/method. When TDD focuses on code-test-driven-development instead of functionality-tests-driven-dev, the overheads add up significantly. (NOTE: I am not at all discounting the benefits of code-testing and code-coverages. Just saying these tend to be value-enabler-overheads that many times yield very little) The #2 benefit for developers is ability to develop faster. However non-TDD devs will not immediately buy into this and will need quite some practice before they reap benefits. Also I have noticed certain kinds of projects are better off starting without TDD and introducing tests benefits only after the code grows to a xyz size (and when refactoring makes sense). If it was an application without unit-tests, I wouldn't try to fix it. However, I would write tests to make sure application performs in a certain way in a sandboxed environment - even if it meant testing the functionality via some headless browser.