But if you're having to create lots of mock objects, that's a huge signal that your objects are tightly coupled, and that not only are you writing a bad test, you've written a bad subject-under-test.
Yes, you still have to write integration tests. But the discipline of testing your objects in isolation and outlining the objects they collaborate with is a major benefit of using test doubles, not a downside. If you can't reason about your objects in isolation, how can you expect to reason about them in aggregate?
If you can't reason about your objects in isolation, how can you expect to reason about them in aggregate?
I don't use my objects in isolation.
Maybe I can mock up some factory which creates model objects outside of my persistence mechanism, but what value is that? I care that when I create an object in response to an action from a real user the persistence mechanism produces the correct object.
I happily bulk load testing data into my persistence mechanism for testing purposes, but I see almost no reason to mock it for tests.
Yes, you still have to write integration tests. But the discipline of testing your objects in isolation and outlining the objects they collaborate with is a major benefit of using test doubles, not a downside. If you can't reason about your objects in isolation, how can you expect to reason about them in aggregate?