Ruby/Rails: Onion architecture testing techniques

We are experimenting with moving to an architecture in our Rails applications where we move as much logic as possible out of the models and controllers, and putting them in service objects (plain-old-ruby-objects). One of the major goals is to radically decrease testing time, since these service objects do not have any non-injected dependencies, especially rails. This idea is basically following the onion architecture principles as I understand them.

The issue is with testing: I feel like any layer of the onion should be treated like a black-box API for the next layer above it. And we don't test APIs in general, because much of their value comes from being trustable. The speed of testing also comes from only having to test a given layer in isolation, with any calls to a lower layer mocked out.

But a few members of my team have questioned how do we know that API is being used correctly by the above layer, if everything is mocked out? They feel the only way to be sure that everything is integrating properly is to test all from any given layer all the way down to the dB. But I feel like this will only increase the number of tests and thus suite testing time - the opposite of my goal.

How can I keep my tests to a minimum (but complete) while satisfying their concerns?