You're not really talking about unit tests, then: you're talking about progressive integration tests, since the failure of a module "behind" your module can cause extra spurious failures.

Now, it may in fact be the case that you may argue that you can replace unit tests with all of these sorts of integration tests. I'm not so sure: digging around the private implementation details ways usually the easiest way to test strange error conditions—but it’s by no means easy. Though these days, I try to write as much pure code as possible, nullifying the benefits of an approach like that.