When we first started testing, we were bitten by the “add a fixture and a bunch of random tests break” phenomenon a few times. That was one of our motivations to move heavily into using mock-based testing. After mock-based testing bit us also, we eventually converged on the following approach to test data: use fixtures for things that are really basic and fundamental, and therefore won’t need to be added to often; use the ObjectMother pattern (which goes by many other names, basically a test data factory) for one-off objects with specific states needed by your tests; use mocks when test data setup is just too arduous, or if needed for performance or some kind of external dependency.

Thanks for your comment!

Having said this, mocks are no end-all be-all as some of the fervent proponents have you believe. Mocking association proxies are a pain, for example. I’ve not yet heard a good answer to this.

Some projects out there are trying to centralize the mocks, these may be worth a look.

On a wider perspective, though, I’ve observed a very similar problem to what you’re describing–you make one implementation or API change–and all hell breaks loose with your tests, even in a fixtures-based test environment, and this typically happened when new fixtures were added to add more variety to the demo data, so as to model a new case. The upshot conclusion from this for me has always been that data and tests were too tightly coupled. So, not knowing anything about your application, I wonder if your test granularity (and thus code granularity) is too coarse?