One example of a failure case you'd prefet to catch, is that the object under test uses a caching layer but fails to persist the data as required. Then if you query the object it'll say "yup, I've got the new name and address", but you want the test to fail because it hasn't actually done what it was supposed to.
Alternatively (and overlooking the single-responsibility violation), suppose it's required to persist a UTF-8-encoded version of the string to a byte-oriented field, but actually persists Shift JIS. Some other component is going to read the database and expects to see UTF-8, hence the requirement. Then the round-trip through this object will report the correct name and address because it'll convert it back from Shift JIS, but the error isn't detected by your test. It hopefully will be detected by some later integration test, but the whole point of unit tests is to catch problems early, and know exactly what component is responsible.
If one of them is not doing what it's supposed to, then its own test case will fail and we can fix it and run the test battery again.
You can't assume this, because if you're not careful you write a mutually dependent set of tests. The "does it save?" test calls the save method it's testing, and then the load method to confirm it saved. The "does it load?" test calls the save method to set up the test fixture and then the load method it's testing to check the result. Both tests rely on the correctness of the method they aren't testing, meaning that neither of them actually tests the correctness of the method it is testing.
The clue that there's a problem here, is that two tests that supposedly are testing different units actually do the same thing. They both call a setter followed by a getter, then check the result is the original value. But you wanted to test that the setter persists the data, not that the setter/getter pair works together. So you know something's wrong, you just have to figure out what and fix the tests.
If your code is well-designed for unit testing, then there are at least two ways you can test whether the data has really been correctly persisted by the method under test:
mock the database interface, and have your mock record the fact that the proper functions have been called on it, with the expected values. This tests the method does what it's supposed to, and is the classic unit test.
pass it an actual database with exactly the same intention, to record whether or not the data has been correctly persisted. But rather than having a mocked function that just says "yup, I got the right data", your test reads back out of the database directly and confirms it's correct. This may not be the purest possible test, because an entire database engine is quite a big thing to use to write a glorified mock, with more chance of me overlooking some subtlety that makes a test pass even though something is wrong (so for example I shouldn't use the same database connection to read as was used to write, because I might see an uncommitted transaction). But it tests the right thing, and at least you know that it precisely implements the entire database interface without having to write any mock code!
So it is a mere detail of test implementation whether I read the data out of the test database by JDBC or whether I mock the database. Either way the point is that I can test the unit better by isolating it than I can if I allow it to conspire with other incorrect methods on the same class to look right even when something is wrong. Therefore I want to use any convenient means to check that the correct data was persisted, other than trust the component whose method I'm testing.
If your code is not well-designed for unit testing, then you may have no choice, because the the object whose method you want to test might not accept the database as an injected dependency. In which case the discussion about the best way to isolate the unit under test, changes into a discussion about how close it's possible to get to isolating the unit under test. The conclusion is the same, though. If you can avoid conspiracies among faulty units then you do, subject to available time and to anything else you think of that would be more effective at finding faults in the code.