Consumer-driven contract API testing

Consumer-driven contract testing is a way of integration testing a service’s API prior to deploying it to a microservices-based system. It is especially useful when:

• the system under test comprises a lot of microservices, since the number of potential inter-service APIs grows faster than the number of services. (For example, with 4 microservices, there are 12 channels to test, with 40, there are 1560.)
• different teams (or external contractors, or bespoke software development companies) build different services at different times.

Consumer-driven contract testing

With this approach to testing, the developers of a consumer service write “contracts” saying what responses they expect from the requests made to a service provider. It is “consumer-driven” because the consumer’s developers drive the writing of the contract, and lead the negotiations with the provider’s developers. It is an old but still effective way of testing distributed microservice architectures that grow ever more complex and difficult to test.

Typically, the contract is a JSON or XML file that the developers and their services (both consumer and provider) can access.

Mock testing meaning

Implicit in this testing approach is the idea of a mock. A mock is a test harness that emulates a provider’s responses, but only those relevant to the consumer being tested. It lets you detach and isolate a consumer from a system, and test it independently. It can also record the results of tests, so they can be compared with other tests against other components.

When you test an API with consumer-driven contract testing, you look inside a system, and see the relationships between consumers that request, and providers that respond. You test against the mock, not the real provider.

Consumer-driven contract testing and Agile software development

Consumer-driven contract testing works well with Agile software development. It is also useful in cases where companies hire external talent to develop bespoke additions to well-established systems. Such systems are typically complex and difficult to test using conventional end-to-end microservices testing strategies.

With this approach to testing, test cycles are quicker than full end-to-end testing. Tests don’t have to run through a whole system. Instead, they can run on local or lower-specification hardware without launching an entire deployment environment. And because consumer-driven contract testing focuses on a single interface, teststhey are simpler and easier to maintain.

However, defining contracts and implementing mocks takes time and skill. This is something clients don’t always want to pay for. One of my jobs as a QA Architect at BlueSoft is to explain how this approach is not just about automation. It also means we can run tests in parallel on decoupled environments run by independent teams. Doing so, we actually reduce the total cost of integrating new services.

This kind of testing should be done early in the development life cycle when change costs are lower. But, it should not be started before APIs have stabilized to some degree.

Further reading

Tools that support some form of contract testing:

• Postman – A popular API development and testing app.
• Spring Cloud Contract – A testing framework for Java and the Spring framework.
• Hoverfly – an API simulation tool.
• WireMock – an HTTP API simulator.
• Pact – Probably the most popular contract testing tool. It includes a contract broker and mock service provider.