Yeah, but it’s the type of tests that are often the problem. You need tests that cover the functional (and as much as possible, non-functional), requirements of

Yeah, but it’s the type of tests that are often the problem. You need tests that cover the functional (and as much as possible, non-functional), requirements of each “component”. In practice, we tend to have a pile of tests that helped the developer write the code, but now are simply redundant. Then you have all the tests that assert on internal details (strings in error messages anyone?). My favorite guide to testing well is in “Large-Scale C++ Software Design” by John Lakos. The problem at its heart is one of engineering practices. Structuring code bases physically into definable components/modules, interacting only via defined api’s/interfaces and providing test suits that both document and verify the contracts. Done right, refactoring/rewriting involves no, or extremely minimal, changes to the tests. It can be done right, but it requires significant discipline.