Contract Testing for Microservices: A Complete Guide

Everybody’s doing microservices now-a-days, but the teams keeps getting the same challenges over and over again and what they are really struggling with is:

💡 I switched to microservices to boost my business agility, but now I'm in a bit of a bind. I can make sure each piece of the puzzle works fine, but when it comes to ensuring the whole system runs smoothly, I'm kind of lost. Testing everything together ends up erasing most of the benefits of using microservices. It turns into a real headache – it's tough, expensive, and just plain annoying to set up.

-Holly Cummins, Quarkus

Companies, like Uber, even planned to switch from microservices to something they called “macroservices” due to the granular nature of microservices.

Where the Testing Pyramid lacks when it comes to testing microservices?

Initially, the testing pyramid worked well for testing monolith architecture. But when microservices came into picture, unit tests and E2E tests simply failed. Some major issues with the Martin Fowler’s pyramid are:

➡️Testing for System-Level Confidence: Component level tests are comfortable and fast to implement. But the confidence slowly fades away when the number of services, endpoints, and integrations keeps on growing when new features are implemented. While it's important to test individual components, the real test comes when everything is integrated.

➡️Hurdles with High-level testing: End-to-end tests are slow, prone to errors, hard to debug, and non-deterministic in general. Sometimes teams even avoid running them because of the high effort. They fail to data errors, and no one wants to spend time debugging them. It is not rewarding to debug and fix errors that are only related to the testing environment and not to the actual features of the system.

And that’s where devs and QA folks started exploring other approaches for microservices testing. This is where contract testing came forward as a tailored solution for microservices. It offers a simpler and more manageable way to ensure these services talks and performs as decided.

What is Contract Testing?

Contract testing is a way to test integrations between services and ensure that all the integrations are still working after new changes have been introduced to the system. This allows for faster, more focused testing since only the interactions are tested.

💡 The main idea is that when an application or a service (consumer) consumes an API provided by another service (provider), a contract is formed between them.

This means that the services are no longer fully isolated from each other. The services are not directly connected either, like it happens with end-to-end tests. Instead, they are indirectly connected, and they communicate with each other using the contracts as a tool.

How Does Contract Testing Works?

Contract testing involves establishing and validating an agreement between two parties: the "Provider" (service owner) and the "Consumer" (service user).

There are two main approaches to contract testing: consumer-driven and provider-driven.

👉Consumer-driven Contract Testing:

Consumer-driven contract testing is an approach where the consumer of a service takes the lead in defining the expected behavior of the service they depend on. They specify the contracts (expectations) that the service provider should meet, and then run tests to ensure that the provider complies with these contracts.

This approach puts consumers in control of their service dependencies and helps prevent unexpected changes or regressions in the service they rely on.

👉Provider-driven Contract Testing:

Provider-driven contract testing is initiated by the service provider. In this approach, the provider defines the contracts that consumers should adhere to when interacting with the service. The provider sets the expectations and provides these contracts to consumers.

Consumers, in turn, run tests to ensure that their usage of the service complies with the contracts specified by the provider. This approach allows the service provider to have a more proactive role in maintaining the integrity and stability of the service.

👉Working of Consumer-driven Contract Testing:

➡️The contract contains information about how the consumer calls the provider and what is being used from the responses.

➡️As long as both of the parties obey the contract, they can both use it as a basis to verify their sides of the integration. The consumer can use it to mock the provider in its tests.

➡️The provider, on the other hand, can use it to replay the consumer requests against its API. This way the provider can verify that the generated responses match the expectations set by the consumer.

➡️With consumer-driven contracts, the provider is always aware of all of its consumers. This comes as a side product when all the consumers deliver their contracts to the provider instead of consumers accepting the contracts offered by the provider.

Benefits of Contract Testing

➡️Maintenance: They are easier to maintain as you don't need to have an in-depth understanding of the entire ecosystem. You can write and manage tests for specific components without being overwhelmed by the complexity of the entire system.

➡️Debugging and Issue Resolution: Contract tests simplify the debugging process. When a problem arises, you can pinpoint it to the specific component being tested. This means you'll often receive precise information like a line number or a particular API endpoint that is failing, making issue resolution more straightforward.

➡️Local Bug Discovery: Contract tests are excellent at uncovering bugs on developer machines during the development process. This early detection helps developers catch and fix issues before pushing their code, contributing to better code quality and reducing the chances of defects reaching production.

➡️Integration Failures: If discrepancies arise during either phase of Contract testing, it signals a need for joint problem-solving between the Consumer and Provider.

Use-cases of Contract Testing

Contract testing is a useful way to make sure microservices and APIs work well together. But it's not the best choice for all testing situations. Here are some cases where contract testing is a good idea:

✅ Microservices Communication Testing:

Use Case: In a microservices architecture, different services need to communicate with each other. Contract testing ensures that these services understand and meet each other's expectations.

# Consumer Service Contract Test
def test_consumer_service_contract():
    contract = {
        "request": {"path": "/user/123", "method": "GET"},
        "response": {"status": 200, "body": {"id": 123, "name": "John"}}
    }
    response = make_request_to_provider_service(contract)
    assert response.status_code == 200

# Provider Service Contract Implementation
def make_request_to_provider_service(contract):
    # Code to handle the request and provide the expected response
    pass

✅API Integration/ Third-Party Integration Testing:

Use Case: When integrating with external APIs, contract testing helps ensure that the application interacts correctly with all the third-party APIs, preventing any compatibility issues and ensure that the code is reliable and secure.

# Contract Test for External API Integration
def test_external_api_contract():
    contract = {
        "request": {"path": "/products/123", "method": "GET"},
        "response": {"status": 200, "body": {"id": 123, "name": "Product A"}}
    }
    response = make_request_to_external_api(contract)
    assert response.status_code == 200

# Code for Making Requests to External API
def make_request_to_external_api(contract):
    # Code to send the request to the external API and handle the response
    pass

✅ UI Component Interaction Testing:

Use Case: Contract testing can be applied to UI components, ensuring that interactions between different parts of a web application, like front-end and back-end, work as expected.

// Front-End UI Component Contract Test
it('should display user data when provided', () => {
    const userData = { id: 123, name: 'Alice' };
    const component = render(<UserProfile data={userData} />);
    const userElement = screen.getByText(/Alice/);
    expect(userElement).toBeInTheDocument();
});

// Back-End API Contract Implementation
app.get('/api/user/123', (req, res) => {
    res.status(200).json({ id: 123, name: 'Alice' });
});

Difference Between Contract Testing and Integration Testing

Contract testing and integration testing are sometimes mistaken for one another; despite sharing a common end goal, they diverge significantly in their approaches.

Contract testing is about adhering to agreements between services, while integration testing is about achieving seamless operation when components are combined. Both types of testing are complementary and important in their own right.

Tools to Perform Contract Testing

Numerous tools exist in the market for conducting contract testing on APIs and microservices. Pact and Spring Cloud Contract are two of the most prominent tools in the realm of contract testing, widely recognized for their specific features and capabilities:

Let’s discuss the two of them:

➡️PACT:

PACT stands out in the contract testing domain for its user-friendly interface and flexibility across various programming languages. Pact enables both consumers and providers to define and verify their contracts effectively.

It operates on a consumer-driven approach, meaning the consumer code generates the contract. This approach encourages consumer specifications to be fully considered in the contract, ensuring that the provided service meets these requirements.

Pact’s versatility extends to support for numerous programming languages, including Ruby, JavaScript, and JVM languages, catering to a wide range of development environments.

Here’s a complete guide on how PACT contract testing works and where it still falls short.

➡️SPRING CLOUD CONTRACT:

This tool is specifically tailored for Java applications, particularly those developed using the Spring Boot framework.

Unlike Pact, Spring Cloud Contract adopts a provider-driven approach. It allows providers to define and verify their contracts, using Groovy or YAML for contract descriptions. This tool excels in automating the generation of test cases from these contracts, seamlessly integrating these tests into the build process.

This integration ensures that any changes in the service are immediately tested against the contract, thereby maintaining consistency and reliability in service interactions.

We've covered PACT in detail here; head over now to get more insightful information here.

Check out our other contract testing resources for a smooth adoption of this highly agile and proactive practice in your development flow:

• Tailored Approach To Test Microservices

  
  

• Comparing Pact Contract Testing and HyperTest

• Checklist For Implementing Contract Testing