If I understand your question correctly, you want to test integration without integrating. I consider that mocks and stubs and fakes and so on should be used to control the indirect input and output and to properly test behavior when necessary. That is what Gerard Meszaros says in xUnit Test Patterns: Refactoring Test Code.

If I would have a class A and a class B I would use mocks to test each separately, exactly as you specified.

However, an integration test should exercise both objects. The integration tests should only cover the paths leading to communication between the objects. These communications should happen, for real. What you suggest is not quite right for integration testing. It is doable from a technical point of view, but it is not right from the point of view of the level of testing you want to do.

Of course, you can mock, stub, fake, etc. any D, E, F ... Z classes needed to initialize A and B. In some more complex situations, you can even partially mock A and B, so that some methods will return what you want without doing tons of computations, but the parts communicating between the two classes should remain real, always.

If I understand your question correctly, you want to test integration without integrating. I consider that mocks and stubs and fakes and so on should be used to control the indirect input and output and to properly test behavior when necessary. That is what Gerard Meszaros says in xUnit Test Patterns: Refactoring Test Code.

If I would have a class A and a class B I would use mocks to test each separately, exactly as you specified.

However, an integration test should exercise both objects. The integration tests should only cover the paths leading to communication between the objects. These communications should happen, for real. What you suggest is not quite right for integration testing. It is doable from a technical point of view, but it is not right from the point of view of the level of testing you want to do.

Of course, you can mock, stub, fake, etc. any D, E, F ... Z classes needed to initialize A and B. In some more complex situations, you can even partially mock A and B, so that some methods will return what you want without doing tons of computations, but the parts communicating between the two classes should remain real, always.