Today I got that feeling of how the use of one word, interpreted differently by different people result in misunderstandings. It was when I read this which IMHO is full of misunderstandings (including some of the comments). One example is that refactorings must break unit tests. No that can never happen because refactoring is about changing internal structure and design without changing the functionality. What is typically a pain with a bunch of unit tests in place is when you realize your design sucks and you want to rewrite something. The border when you go from refactor to rewrite may be gray but refactorings are always small and should never change the functionality (including the API). So when I say unit tests makes it easier for me to do refactorings that says nothing about when I need rewrite/change something.
There is a valid point that having unit tests means you have to change unit tests when you need to rewrite/change something. But if you’ve written your unit tests and code in a good way this impact should be small. Just because you feel something makes your life harder sometimes does not mean it is wrong, it might mean you’re doing it wrong. And one way to prevent yourself from having to do these cumbersome rewritings is to make sure your code is very simple and that each entity only does one thing. Something that happens almost by itself if you’re doing TDD… In my experience, every time I find a solution hard to test or hard to change because the tests breaks massively with a small change, it does not mean TDD is a bad idea. It has always meant that I should solve the problem in a different way where the code is easy to test and tests are not fragile.