1

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?

john
  • 141
  • 4
  • 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. – Stop harming Monica Jul 30 '18 at 09:49

1 Answers1

2

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.

Steve Chamaillard
  • 1,691
  • 1
  • 11
  • 20