I have the exact opposite opinion on "code lockdown". I believe that unit and integration tests heavily lock down code, so much as being mere checksums.
In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful.
On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.
Well designed tests lock down features not code.
That's why I mostly write integration tests.
I write unit tests once the project is stable and usually only for parts of the logic that are either very complicated or operationally critical. I try to avoid implementing 'very complicated' modules as much as possible.
Do you mean e2e tests? Because those are the only ones that test features. Integration tests are the biggest offenders of "code lockdown". They don't really test features, yet they have to observe too many implementation details.
Unit tests can't really lock down code, or then we shouldn't call those "unit" anymore.
In a project with >90% coverage, I would find refactors dreadful. After any substantial change beyond adding stuff, there were always a myriad of tests failing. Not hard to fix, but simply tedious and dreadful.
On the other hand, I have an Elm project with no unit test, only some e2e tests. I can do huge transversal changes, and I don't find ot tedious at all. It gave me back the fun in programming. The Elm project is a game, so there should me an order of magnitude more bugs, but the opposite was the case.