How do I create an integration test that tests multiple microservices without mocking?

Question

I understand the concept of mocking API responses and their uses in unit testing, but in functional/integration testing, I actually don't want to mock because that defeats the purpose.

For example, if I have microservice A and B. A user creates a record with A, and A needs to send some data to B, and B creates another record on its end. B requires parameters 1, 2, and 4. However, in a mock, there is nothing that will guarantee the contract of service B because that API call isn't actually made.

Right now I have a docker container for each service, and I'm sort of lost on how to create this test.

The only thing I can think of is:

• Spin up the containers required for the test
• Create record with microservice A
• Test the existence of the record in A
• Don't mock the call from A to B (so that B also creates its own record)
• Test the existence of the record in B
• Spin down the containers

Any ideas on how best to do this?

• autophage: It sounds like you have a good handle on what the steps should be. It sounds like your question might be more "how to structure the testing harness". Is that the case? (Either way, I might phrase "Don't mock the call from A to B" a bit differently - rather than explaining what you're not doing, explain what you are. In this case, presumably, "Call B from A", or something like that.)
• Stop harming Monica: "there is nothing that will guarantee the contract of service B" You can write contract tests and make B pass them.

Answer 1

You shouldn't test point 5 (verifying that B has created a record) in that test that exists in project A.

Instead what your test is about is verifying that A implements the contract of B the right way. Trust B to do its work properly.

Also this is the first step to do this. But to be more complete, I would instead test only a class (let's call it BImp) making calls to B with every possible way. That way you'd create a record in A and then assert your BImp implements B rightfully, then another test would be not to create a record in A and proving that BImp still implements the error returns of B rightfully in that context.

After that, since Bimp is fully tested and under control, you could replace direct B calls in higher levels with BImp calls and mock it out to try every paths. That also allows a easier separation of your integration tests (of BImp) since they will be slower, and of course you won't have to test B again for real if you have to use it in another segment of your code.