I agree coupling your tests to your code will cause resistance to refactoring as the tests have to change w/ the code. Lack of coverage also causes the resistan

I agree coupling your tests to your code will cause resistance to refactoring as the tests have to change w/ the code. Lack of coverage also causes the resistance due to breaking things. I think you have to find a balance. We write almost entirely integration tests (and lots of them) and we rarely need to maintain tests since they're only tied to the UI. Most refactors happen w/ no test changes at all. Occasionally a UI change causes a big find/replace across lots of tests. The tests are also probably less comprehensive than a suite of finer grained tests would be. Most tests tend to cover happy path and few edge cases. When we started there were zero tests and refactoring was too risky so the early code decisions largely had to follow the architecture that was already present (which wasn't always what we wanted). As we filled out the tests for existing behavior we could refactor more. I think the mostly-integration-testing approach led us to a pretty good balance by only coupling the test to the UI (with its own cons of course).