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.

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)?

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?