Write tests that ensure each subroutine is called with specific parameters, so that functionally identical modifications cause the test to fail. Any change to the code now requires a change to several tests.
TDD will leave you with a load of tests which prevent you from changing the code. BDD on the other hand should leave you with a suite that isn't coupled to a specific implementation.
Part of the information contained in a test is the intent of the verification being performed, and part is code for mapping that intent onto the implementation. The latter part can be discarded during a rewrite. Cucumber/SpecFlow etc. make the difference between these explicit.
The thing is, unit tests that are affordable to implement, are not wort it. Their objectives should rather be verified with language choice, programming techniques, and assertions. Tests that are worthwhile to write are those that test interactions of multiple subsystems. But those are not unit tests any more. If you end up _actually needing_ TDD, then that proves you are using the wrong language and/or the wrong technique.
> Well, technically speaking I can rewrite it, but no-one will mind.
Try that on multiple teams across timezones actively developing multiple branches, with big merges on a weekly basis.
"Rewrite module X" never happens. Even if you have a healthy suite of behavioral tests, it will still feel brittle because rewriting large sections of code will inevitably bite you in the ass.
And no you can't say "you're merging main into your branch? your responsibility."
1. Don't write fast running behavioural tests that verify the software is working as required.
With fast running tests I can maintain any old crap. Well, technically speaking I can rewrite it, but no-one will mind.