I agree but also think it's worth acknowledging the trade off you're making. If you never touch a piece of code, then at some point nobody remembers or is able to understand what it's doing.
I think this is worse than changing code that has been field tested but admit I am biased because I work on a large project where we are beginning to run into this problem.
As long as the process had been that the only way to get a pull request for a bugfix accepted is by proving the bugfix worked with an automated regression test, then you can change the code as much as you want...
Tests lock you down to particular design by way of the interface. If you want to fundamentally redesign something, you're likely going to have to change the tests as well.
The power of automated testing is really to ensure that nothing changes, which is great when doing bug fixes, but not so great for actually evolving software.
Ultimately it just becomes easier to add new code than it is to ever change a design that is already in place.
Sounds like you are writing tests at the wrong level then.
I was talking about a regression test for a fix for a bug found in production. For a typical backend, write such tests against the publicly exposed API.
If you end up breaking tests as you refactor it means that you have broken backwards compatability for others who use the API...
We seem to be talking at cross-purposes here. I agree that tests enforce backwards compatibility (or compatibility in general) but they also enforce a particular design. Fundamentally redesigning something generally involves breaking the testa and the API.
To put it another way, if you never break your tests you can only ever fix bugs or add more code -- you can never remove code or redesign.
This assumes that if you rewrite a piece of code then the possible bugs in the new code are similar to the bugs in the old code. And that is in general not true.
I think this is worse than changing code that has been field tested but admit I am biased because I work on a large project where we are beginning to run into this problem.