Summary:

Contract testing is a specialized software testing method/technique used to confirm the communication between different microservices or components within a distributed system. In the complex landscape of microservices architecture, where numerous services interact, contract testing guarantees that each service is equipped to communicate seamlessly with its dependencies.

There are two primary types of Contract Testing:

• Consumer-Driven Contract Testing
• Provider-Driven Contract Testing.

1. Consumer-Driven Contract Testing –

Consumer-Driven Contract Testing is also known as CDCT and is a testing method/approach where the users of a service (like client apps or microservices) outline their expectations (contracts) for how they want that service to work. These contracts are then used to check if the service provider (the server-side system) meets these expectations. In simpler terms, it’s like setting rules before playing a game to make sure everyone knows how to play and follows the same rules throughout.

Consumer-Driven Contract Testing

• With the Pact DSL, we define the expected request and response for the mock service.
• The consumer’s test script sends a real request to a mock provider set up by the Pact framework.
• The mock provider checks if the actual request matches the expected request and sends back the expected response if they match.
• The consumer’s test script confirms that the response received is as expected.

2. Provider-Driven Contract Testing –

Provider-Driven Contract Testing (PDCT) is a testing approach where the service provider (server-side implementation) defines how the service should behave and specifies these expectations as contracts. Consumers (such as client applications or microservices) then use these contracts to ensure that their interactions with the service adhere to the specified behavior. In other words, the provider sets the rules or guidelines for how the service should work, and consumers verify that they follow these rules when using the service.

Provider-Driven Contract Testing

Let’s take an example based on an online food delivery service like Swiggy to explain contract testing in the context of microservices.

• UI/User Service: Manages user authentication, profiles, and order history.
• Order Service: Handles placing and tracking orders.
• Restaurant Service: Manages restaurant details, menus, and availability.
• Payment Service: Handles payment transactions.
• Notification Service: Sends order updates to users via SMS or notifications.

Now, all these microservices interact with each other’s to complete an order.

For Example:

When a user places an order through the UI user service of Swiggy app, the Order Service is responsible for capturing and processing the order. And The Order Service then communicates with the Restaurant Service to fetch menu items and availability. Once the order is confirmed, the Order Service might interact with the Payment Service to process the payment. And after the order is placed, the Notification Service sends order updates to the user.

In this above example all the services have been their own microservices and each microservice defines a contract that specifies its expected interactions with other services. For example, the Order Service might define a contract specifying the expected format and data required when interacting with the

Restaurant Service to place an order. This contract we must test verify whether it is getting correct or not if any changes done in services.

Usage:

• Early detection of compatibility issues between microservices
• Improved collaboration among teams working on different services.
• Efficient validation of service interactions within distributed systems
• Reduced risk of integration failures in production
• Clear documentation of service expectations through defined contracts

Structure:

The structure for the integration of PACT java with JUnit Maven framework.

PACT consumer test framework structure –

PACT consumer test framework structure

PACT provider test framework structure –

PACT provider test framework structure

Here is the PACT consumer test example-

Here is the PACT consumer test example

Here is the PACT provider test example-

Here is the PACT provider test example

Key Features:

PACT Consumer Testing Features –

• Consumer Contracts: Empowers the consumer to establish expectations from the provider.
• Mock Server: Utilizes a mock server to emulate provider responses during test execution.
• Interactions: Defines detailed request and response interactions, encompassing headers, body content, and status codes.
• Flexible Matching Rules: Offers adaptable matching rules for request and response validation, including regular expressions and type matchers.
• Automated Test Generation: Automatically produces test cases based on the specified interactions.
• State Management: Facilitates setting up various states in the consumer to test multiple scenarios.
• Seamless Integration: Easily integrates with unit testing frameworks.
• Verification After Each Test: Ensures verification of each interaction following test execution.
• PACT File Creation: Creates PACT files that articulate the consumer’s expectations in a JSON format.

PACT Provider Testing Features –

• Provider Verification: Confirms that the provider fulfills the consumer’s expectations as outlined in the PACT file.
• Stateful Testing: Enables the configuration of various provider states to align with consumer-defined scenarios.
• Contract File Integration: Utilizes PACT files generated by consumers for verification purposes.
• Automated Verification: Streamlines the process of validating the provider against the consumer contracts.
• Reports: Delivers comprehensive reports on mismatched interactions and verification outcomes.
• CI/CD Integration: Seamlessly integrates with CI/CD pipelines to maintain continuous verification.
• Flexible Configuration: Allows customization of the verification process to suit specific requirements and environments.
• Pact Broker Integration: Connects with the Pact Broker to handle and distribute PACT files and verification results.

Test Reporting:

JUnit Framework supports reporting as:

• Extent Report
• Junit HTML Report

Add Ons:

• Compatible with various programming languages such as Java, JavaScript, Ruby, .NET, and Python.
• Emphasizes consumer-driven contracts, guaranteeing mutual agreement on API behavior between consumers and providers.
• Automatically ensures that microservice interactions adhere to the defined contract.
• Features robust matchers to manage dynamic data and provide flexible validation.
• Easily integrates with testing frameworks like JUnit, Mocha, and others.
• Boasts an active, supportive community with a wealth of examples and use cases available online.

Conclusion:

Pact contract testing ensures reliable interactions between microservices and APIs through consumer-driven contracts. It supports multiple programming languages and integrates smoothly with popular testing frameworks, making it versatile for development teams. Though there may be an initial learning curve, Pact’s automated contract verification, early detection of issues, and enhanced collaboration via tools like the Pact Broker make it a valuable addition to any microservices testing strategy.

Ref Link :

https://docs.pact.io/

https://docs.pact.io/pact_broker

https://docs.pact.io/getting_started/how_pact_works