Well, it has a lot of uses. For developers that are new to a largish code base, it can help them ensure they don't break important subsets (as would any good u

Well, it has a lot of uses. For developers that are new to a largish code base, it can help them ensure they don't break important subsets (as would any good unit testing strategy). But also it proves to be quite handy when you have a really complex system that grows over time. When you go to refactor it to keep it evolving and working, the tests throughout (while costly to maintain) give you more reassurance that you didn't wreck the world. TDD adds costs but reassurance that you don't break major things during a refactor. It can get a bit cumbersome at times, but it's hard for me to avoid seeing the value for long-lived code (i.e. non-prototypes) and/or shared code. It's not for everyone or everything, but I think it's pretty reactionary for anyone to say it's not a useful process to have in your toolbox. For example, I recommend TDD for cases where you're making a public API to unknown people. It's much more likely you'll break some unknown importance nuance in a refactor unless you have a good number of comprehensive unit tests. If you can generate those in some other fashion, awesome-- but TDD puts you ahead of the game there. For me, I also don't have the best long-term memory on details given how many vastly different projects/technologies I work on, so TDD is basically encoding that memory for me so I don't make multi-tasking mistakes for problems I've already solved a month or few weeks ago and helps pass on that memory to people who inherit that code later. I'm an aggressive commenter for that reason, too, but nothing helps you keep cross-component issues solid than unit tests designed to be the canary in the coal mine when you break something in a refactor.