Our systems often depend on 3rd party services (They may even be services internal to the company that we have no control on). Such services include Social Networks exposing APIs, SaaS with APIs like Salesforce, Authentication providers, or any system that our system communicates with, but is outside our product lifecycle.
In regular integration tests, we would have an integration deployment of all sub-systems, in order to test how they work together. In case of external services, however, we can only work with the real deployment (given some API credentials). What options do we have to write integration tests, i.e. check if our system properly integrates with the external system?
If the service provides a sandbox, that’s the way to go – you have a target environment where you can do anything and it will be short-lived and not visible to any end-users. This is, however, rare, as most external services do not provide such sandboxes.
Another option is to have an integration test account – e.g. you register an application at twitter, called “yourproduct-test”, create a test twitter account, and provide these credentials to the integration test. That works well if you don’t have complex scenarios involving multi-step interactions and a lot of preconditions. For example, if you application is analyzing tweets over a period of time, you can’t post tweets with the test account in the past.
The third option is mocks. Normally, mocks and integration tests are mutually exclusive, but not in this case. You don’t want to test whether the external service conforms to its specification (or API documentation) – you want to test whether your application invokes it in a proper way, and properly processes its responses. Therefore it should be OK to run a mock of the external system, that returns predefined results in predefined set of criteria. These results and criteria should correspond directly to the specifications.
This can be easily achieved by running an embedded mock server. There are multiple tools that can be used to do that – here’s a list of some of them for Java – WireMock, MockServer, MockWebServer, Apache Wink. The first three are specifically created for the above usecase, while Apache Wink has a simple mock server class as part of a larger project.
So, if you want to test whether your application properly posts tweets after each successful purchase, you can (using WireMock, for example) do it as follows:
@Rule
public WireMockRule wireMockRule = new WireMockRule(8089);
@Test
public void purchaseTweetTest() {
stubFor(post(urlEqualTo("/statuses/update.json"))
.willReturn(aResponse()
.withStatus(200)
.withHeader("Content-Type", "application/json")
.withBody(getMockJsonResponse()));
// ...
purchaseService.completePurchase(purchase);
verify(postRequestedFor(urlMatching("/statuses/update.json"))
.withRequestBody(
matching(".*purchaseId: " + purchaseId + "*")));
}That way you will verify whether your communication with the external service is handled properly in your application, i.e. whether you integrate properly, but you won’t test with an actual system.
That, of course, has a drawback – the rules that you put in your mocks may not be the same as in the external system. You may have misinterpreted the specification/documentation, or it may not be covering all corner cases. But for the sake of automated tests, I think this is preferable to supporting test accounts that you can’t properly cleanup or set test data to.
These automated integration tests can be accompanied by manual testing on a staging environment, to make sure that the integration is really working even with the actual external system.
| Reference: | Integration Tests for External Services from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog. |
