> You've talked around my core point a lot, but you haven't addressed it directly at all.

I thought I addressed it quite directly.

> What do you do about bugs on the interfaces and interaction of the heavily modularized and unit-tested components?

Ideally, catch them with the unit tests -- whose entire purpose is testing interfaces -- but, where that fails, with traditional integration tests (which, when they find bugs missed by unit tests, prompt additional unit tests to isolate the offending unit and assure that they are properly squashed) rather than by abandoning unit and integration testing for something that isn't quite either and lacks the specificity and utility for test-on-each save of unit tests while abandoning the full end-to-end cycle testing of integration tests.

Your unit test guarantees the intended interface of the unit, but it doesn't guarantee the usage of said interface. Typically other unit tests will stub out this dependency. But what is your guarantee that the stub agrees with the spec'ed behavior.

Now this may range from a non-issue if the interface is obvious and straightforward and leaves little room for error, to extremely error-prone in a duck-typed language. Of course there are ways to mitigate this with the test and stubbing infrastructure, but it can be brittle as well.

This problem is why I think there is some sense of coarser-grained units with fewer stubs and some qualities of integration without going all the way up to the full-path acceptance level.