There's only one rule:
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.
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.
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.
Wait, what?! The more I listen people talking about TDD, the more I discover I always misunderstood it, and the less I want to actually understand it.
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."