I usually go the other way around: uncle Bob said that "refactoring represents small changes in the code that keep the tests passing". With that in mind, we should never start refactoring without having the code covered.
I would agree in the situation where the units of code that you are testing have some minimum amount of encapsulation and separation of concerns. If however you would need to refactor your tests in order to begin refactoring your code then at least some code refactoring would need to come first. However most of the time what you described would be the preferred scenario to be in but I was wanting to highlight a scenario that does not fit into the normal pattern of refactoring and unit testing.
Sometimes it is the interaction and interface between functions and classes that need refactored. It is of no benefit to add a unit test to an interface which does not isolate concerns, provide abstraction, or encapsulation only to then refactor that interface.
I usually go the other way around: uncle Bob said that "refactoring represents small changes in the code that keep the tests passing". With that in mind, we should never start refactoring without having the code covered.
I would agree in the situation where the units of code that you are testing have some minimum amount of encapsulation and separation of concerns. If however you would need to refactor your tests in order to begin refactoring your code then at least some code refactoring would need to come first. However most of the time what you described would be the preferred scenario to be in but I was wanting to highlight a scenario that does not fit into the normal pattern of refactoring and unit testing.
If refactoring breaks your tests means either your tests are fragile or your code is not SOLID. Let's not confuse refactoring with change requests
Sometimes it is the interaction and interface between functions and classes that need refactored. It is of no benefit to add a unit test to an interface which does not isolate concerns, provide abstraction, or encapsulation only to then refactor that interface.
Exactly.. if the code follows the SOLID principles, it's easier to write tests that won't break at the smallest code change.