It seems like you're talking about the problem of having overly fragile tests. Getting a test to break when something is actually broken is something that come

It seems like you're talking about the problem of having overly fragile tests. Getting a test to break when something is actually broken is something that comes with experience and studying good tests. For example, a novice test writer would serialize a Java object and compare it against a previously serialized object byte for byte. This would break as soon as there was a trivial change to the object. A better procedure would be to run pre-test and post-test assertions on the properties of the object that were actually important. If you have good tests and change something and a bunch of the tests breaks, that simply means you broke a lot of stuff. At least you'll know what's broken instead of having it thrown back and forth over the wall between Dev and QA a hundred times to get it out the door.