We use mock to ensure that a unit test only runs against the code that should be tested. This prevents that a bug in a module A causes tests of a dependent module B to fail. However, now we also have to test the interaction explicitly. It is not enough that A and B are green on their own, A has to work as B expects it, and B has to have the right expectations.
Now, B’s expectations are already formally defined: in the mocks and stubs. If I have a stub where A returns certain output for certain input, this means I expect it must be possible to have A in a state where it shows this behavior.
So instead of writing long integration tests, I just have to set-up an A and test it against the stubs and mocks that are already there. Or, to turn it around, I can use an actual instance of A to test the correctness of my mocks.
Does this work in practice? Are there best practices (e.g., where do these pseudo-integration tests belong to, should A’s test suite already provide some likely-to-be-used mocks)? Is this even possible with the popular mocking frameworks?
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.
Does this work in practice?
It can, but the problem comes in instantiating the mock. Often times the integration you’re testing is some sort of instance resolution that spins up and glues together the different pieces; or your deployment scripts. If you change that to spin up mocks, then you’ve violated your test.
So it mostly depends on your specific scenario. There’s nothing particularly wrong with re-use as a general practice here.