Testing API client code resiliency with WireMock Cloud

What you need to know:

• API client code must be able to handle unexpected issues when calling dependent APIs. 
• It’s difficult to make API producers respond in deterministic ways to test the resiliency of consumer code. 
• WireMock Cloud can be used to test API client code resilience through its stateful scenarios and Chaos Engineering features. 
• Use these features to test product reliability in unexpected fault scenarios by incorporating errors in your mock APIs. 

Watch the video:

WireMock Cloud Academy

Why test API resilience?

API resilience is all about building robust APIs that continue to function despite the various challenges that exist in production environments. 

External and internal APIs can suddenly become unavailable for various reasons, leading to stability issues for the apps that rely on them. Resilience testing ensures that any apps that rely on external APIs can handle sudden failures in a way that minimizes the end-user impact. It can help overcome failure scenarios such as rate limits by enabling dev teams to identify issues and implement fixes in pre-production environments. 

Let’s say, for example, a fintech company has an app that handles money transfers and relies on an external API for reconciliation. It’s mission-critical for them to know how their transfer API functions when the external reconciliation API goes down. Resilience testing makes it easy to determine what might happen and, by extension, what to do in such failure scenarios, helping their dev team get back up and running and avoid potential compliance issues. 

However, it’s not easy to force external APIs to fail in a specific way for testing purposes. Failures generally happen unexpectedly and when they do happen, the failure scenario isn’t guaranteed to match the one you need to test. This is where API mocking and fault injections come in. These provide ultimate control and flexibility to engineer and run various test scenarios in a controlled environment. 

Gaming failures with fault injections

Dev teams primarily use fault injections to generate failure scenarios for resilience testing when mocking APIs. Fault injections stress-test an app by creating disruptive events and failures, making it possible to observe how it responds. This information can then be used to improve the performance and overall resilience of applications so that they behave as intended. 

Although helpful, fault injections can only be used to test specific, preconceived scenarios. As we all know, not all failures are predictable, and it’s the unpredictable failures that cause the biggest headaches. To get around fault injection limitations, dev teams use chaos engineering to generate unplanned failure scenarios. 

Using chaos features to restore order in your testing 

Chaos engineering helps dev teams to simulate a wide range of failure scenarios. This is achieved by introducing random chaos elements that stress-test your app and demonstrate how it stacks up against various fail states such as long delays, outages, and timeouts. 

The detailed level of insight that can be achieved with chaos engineering gives dev teams an understanding of how the wider production environment might be impacted by third-party API errors and service outages. This allows for mitigating fault scenarios and production bottlenecks during testing through more realistic integration testing and the simulation of otherwise hard-to-simulate failure scenarios.

The scenario below shows how chaos features in solutions like WireMock Cloud make it easy to test client code resiliency. Here, we’re running a mock example with a single success scenario. 

Before this scenario is run, we enable Chaos mode and set the failure rate at 75% with several different failure types selected. WireMock will randomly select failure types until the maximum number of retries is reached—four in this case. 

The first time this scenario was run, as shown in the console, there was one aborted connection error and three 400 client errors. 

The second time the scenario was ran, there was one connection broken and one connection aborted error before a successful response was achieved. 

These are simple examples, but they show the value of being able to randomly inject failures and test the resiliency of client code. By subjecting the code to various unexpected errors like connection issues and 400-level client errors, we can see how the client handles these situations. Does it have proper retry logic and error handling to eventually get a successful response despite intermittent failures? Can it gracefully degrade functionality if a dependency is completely unavailable?

Using chaos testing in this way allows teams to proactively find and fix resiliency weaknesses in their client code. It provides assurance that the application as a whole can handle the inevitable unexpected failures that will occur when depending on external services in a production environment. Chaos testing with tools like WireMock Cloud should be a key part of any team's testing strategy to maximize the reliability and stability of their applications.

Watch Dan Perovich, WireMock Head of Sales Engineering, show an end-to-end API resilience test in the WireMock Cloud Academy. 

‍