If you have real unit tests then refactoring code also means refactoring unit tests, as they just test small units like functions in isolation. When refactoring

If you have real unit tests then refactoring code also means refactoring unit tests, as they just test small units like functions in isolation. When refactoring you will need to replace units or delete them to be able to change units that are higher up in the abstraction. You may end up testing a lot of implementation details and keep them from changing. If you only write tests of the higher abstracted units while also using the lower abstraction ones, you are not really doing unit testing anymore but what some people call integration testing. In my opinion they both have their place. Most of the code we write is relatively throw-away code that will be used in one project/occasion and is prone to be changed because of changing requirements. You should test your requirements and functionality with integration tests, unit tests will cost too much time and will stand in your way. In rare cases we write code that is really reusable in a bigger scope and acts like a foundation set in stone that rarely changes and is widely reused. In general you should put way more effort in those and also use unit tests there.