What's the proper way of integration testing libraries that run injected code?

Question

I have two software components: My application and a library (which is owned by my company, but another team), which is used by the application. The library is a client library for some service and performs HTTP requests. The library also maps the HTTP response to the internal representation of the application. This is done by injecting a mapping class into the library by the application.

I already have unit tests for the mapping class and for the application, whereas the client library call is always mocked.

Now I'm thinking of integration test the library and I'm not sure what's the best way to do that:

• Mock the library call and only check that it's called with the correct parameters

  • Pro: If the internals of the library change (with a non-breaking change) I don't have to adapt my tests.
  • Con: The mapping class isn't integration tested. I can't be sure that the library is correctly configured or that the parameters the mapper gets from the library are what I expect them to be.

• Mock only the HTTP call done by the library

  • Pro: The mapping class and the configuration of the library (if I configured it correctly) are tested.
  • Con: I need to figure out the internals of the library and check how the HTTP call of each test case will look like. Also if the library upgrades to a new version of the service, I would need to adapt all the HTTP mocks as well and actually shouldn't care about how the library internally works.

• Replace the HTTP call in the library with an in-memory fake (=dummy) implementation during testing

  • Pro: Everything is tested + the tests are resilient against library changes.
  • Con: It's an effort to implement and maintain a fake implementation. Depending on the service, this could mean rebuilding the functionalities of the service in the library. Who should be responsible (implementation + maintenance) for the fake strategy? My team or the team that owns the library?

I'm in favor of the last point, but given that the internals of our library rarely changes, I'm not sure if a fake strategy is worth the effort.

What's your opinion on this? Can you think of another solution?

Answer 1

I would create helpers inside the library that would allow you to mock the HTTP response. Therefore, you'd see the code running inside the library and you could use the libraries that verify the JSON format to make sure that the http request/response is the one you're expecting.

In this sense, you're checking i) the library actually works with your system; ii) the processes the correct HTTP response; thus, your helper could be easy enough so that developers would only need to provide the content of the http response