0

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?

  • 1
    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.) – autophage Jun 20 '18 at 16:36
  • "there is nothing that will guarantee the contract of service B" You can write contract tests and make B pass them. – Goyo Jul 30 '18 at 9:49
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.