I use the following two approaches combined:

1. Interoperability production or the end-to-end integration flow is black box tested
2. Unit tests cover any business process logic, like data transformations, that is considered to be easier to verify by unit testing than by black box testing.

The test are usually slightly overlapping but I don't see that a problem. You mix these approached in the relevant way for your integration application.

I don't mock business operations in #1, as I don't want to modify system under test, but I mock the external systems and configure the business operations to connect the mocks. For unit testing (#2) the standard software industry mock practices are just fine and have nothing Interoperability specific.

I have seen cases in #1 with both Apache Camel and IRIS Interoperability where the actual integration was changed (i.e. some components where replaced with mocks) for testing but in all cases the outcome was very brittle and hard to maintain test code. Definitely it is possible but moving the mocks out of the integration just made the testing much simpler and straightforward. That's just my experience working with mainly HTTP and JDBC connectivity, YMMV.

You also want to make it trivial to trigger the integration flow programmatically. Sometimes that's extra test only code in your integration but usually not.

In Interoperability you keep your business services and hosts very thin so there should be not much to test so they should usually be covered with rather trivial smoke test cases. You can also inspect the message flow programmatically to verify the correct messaging inside the flow. We have tooling in our in-house testing framework for that (essentially SQL queries to Ens tables).