Thing is, trying to make everything individually testable in tiny bits takes a lot of effort that wouldn't otherwise be needed. Furthermore, with all the mockin

Thing is, trying to make everything individually testable in tiny bits takes a lot of effort that wouldn't otherwise be needed. Furthermore, with all the mocking this usually requires, you end up with tons of extraneous code that now needs to be maintained as well (and by very nature of mocks, you'll have to fix them every time the corresponding real code changes behavior observable across the boundary). In practice, the ostensible benefit of knowing exactly what the problem is as soon as you see the test failure is usually dwarfed by all these costs. And, at the same time, the more mocks you have, the less likely your tests are to catch real issues. Now, as you rightly note, in many cases there's already an obvious component boundary that is inherent in the design. And then it makes perfect sense to write functional tests for individual components along those boundaries. And in some cases, the component may be "library-like", and those tests will end up looking a lot like your typical unit test, where individual classes and even methods are covered one by one. But most classes and methods in a typical app aren't like that.