Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

Integration Tests for External Services

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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


× 3 = nine



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close