I always wonder why so many "TDD or not TDD" discussions. TDD is based on some guidelines (like "Agile"), it works for some, it doesn't for others. It depends o

I always wonder why so many "TDD or not TDD" discussions. TDD is based on some guidelines (like "Agile"), it works for some, it doesn't for others. It depends on many things: tech stack, tooling, team, company culture, etc... just to name a few. Once you get the discipline to follow your version of TDD, then you can focus on more important stuff. You don't spend time on deciding if something has to be tested or not. Having different devs with different level of experience will lead to inconsistent coverage levels. Similar to following traffic/safety rules, you just do it without 2nd guesses. I don't know if I do TDD, but I do write a lot of tests (unit and integration), during code writing. Easy way of mocking components is a huge advantage (e.g. groovy mocking), after all tests is code that needs maintainance. There are multiple reasons to write tests. To me, to get most out of them is TDD or something close to it. Adding tests later, reduces their value, simply because using tests during development is more efficient development (especially in complex systems) than after the fact. All the above is simple IMHO of course.