What is a unit test, really? And is there really such a big dichotomy in play here?
We work in a field where reading literally one bit past the end of a buffer can totally crash a program, or cause it to produce a totally inaccurate result, or as evidenced by the recent "HeartBleed" TLS bug, lay a supposedly secure system wide open without producing any direct evidence of the flaw.
It is impossible to eliminate all complexity from these systems. But our job is, to the extent possible, to minimize and manage that complexity.
Is a unit test a test that confirms, for example, that a reservation is successfully posted in three different systems, a log entry is created and an Email confirmation is sent out?
I'm going to say no. That's an integration test. And those most definitely have their place, but they're also a different topic.
An integration test works to confirm the overall function of an entire "feature." But the code behind that feature should be broken down into simple, testable building blocks, aka "units."
So a unit test should have a very limited scope.
Which implies that the code tested by the unit test should have a very limited scope.
Which further implies that one of the pillars of good design is to break your complex problem down into smaller, single-purpose pieces (to the extent possible) which can be tested in relative isolation from one another.
What you end up with is a system made out of reliable foundation components, and you know if any of those foundational units of code break because you have written simple, small, limited-scope tests to tell you exactly that.
In many cases you should also probably have multiple tests per unit. The tests themselves should be simple, testing one and only one behavior to the extent possible.
The notion of a "unit test" testing non-trivial, elaborate, complex logic is, I think, a bit of an oxymoron.
So if that kind of deliberate design break-down has taken place, then how in the world could a unit test suddenly start producing false positives, unless the basic function of the tested code unit has changed? And if that has happened, then you better believe there are some non-obvious ripple effects in play. Your broken test, the one that seems to be producing a false positive, is actually warning you that some change has broken a wider circle of dependencies in the code base, and it needs to be examined and fixed.
Some of those units (many of them) may need to be tested by using mock objects, but that doesn't mean you have to write more complex or elaborate tests.
Going back to my contrived example of a reservation system, you really can't be sending requests off to a live reservation database or third-party service (or even a "dev" instance of it) every time you unit test your code.
So you use mocks which present the same interface contract. The tests can then validate the behavior of a relatively small, deterministic chunk of code. Green all down the board then tells you that the blocks that comprise your foundation aren't broken.
But the logic of the individual unit tests themselves remains as simple as possible.