So I agree with the sentiment (tests are not a panacea, author says the same), but the first sentence is wrong. A lot of ink gets spilled about TDD on the inte

So I agree with the sentiment (tests are not a panacea, author says the same), but the first sentence is wrong. A lot of ink gets spilled about TDD on the internet... Hoping not to rehash all that stuff, I think I can put forward the point simply: Tests are one of the best (only?) ways to prevent breaking changes to a codebase. If you want to ensure some functionality, a regression test (whether that's unit, integration, or end to end) is the way to do it. Of course, you can't stop someone from coming along and changing the test and invalidating it, but if written correctly a test will offer a 100% guarantee that the codebase fulfills certain requirements. It doesn't matter how much of a mess is made, what matters is that the system remains running at the end of the day (it just gets harder and harder to change, and runs worse and worse). TDD may be a cargo cult, but don't throw the baby out with the bath water -- tests are a useful tool in a software developer's repertoire. This fact should become more and more apparent for any developer who has written lots of software. A good developer, in anticipation of the fact that they will eventually write a bug/commit some regression in functionality, will guard themselves.