Consumer Driven Contract Testing with Testsigma

In consumer-driven contract testing, consumers set rules on how a service should work. They define a contract based on their expectations. The service provider then develops its service as per the contract. The process of testing this service by consumers to make sure everything is as per the contract is called consumer-driven contract testing.

Refer to the image above, the provider service is responsible for providing product-related information. It exposes an API allowing consumers to retrieve product info by its ID number. This information typically includes the product's name, type, and description. The Provider service works as a data source for the consumers. The Consumer service consumes the info provided by the Provider service. It interacts with the Provider service's API to fetch the relevant product data based on the ID number.

Let's understand this with an example. Consider a Testsigma application where the consumer is a frontend web application, and the provider is a Testsigma service responsible for managing. The consumer wants to ensure that the service meets their expectations and behaves correctly.

Here's a generic example of an API endpoint for retrieving product information:

Endpoint: GET/https://prestaging.testsigma.com/api_private/applications/<AppID>

The consumer team defines their expectations and requirements for the endpoint to enable consumer-driven contract testing. In this case, the endpoint allows the consumer to retrieve info about a Testsigma sample app by providing the app ID as a parameter.

The consumer team can then draft the following contract tests as part of their testing process.

Successful Retrieval

Prerequisite:

• An application with the specified <AppID> exists in the system
• Valid API key for the specified environment.

Steps:

• Create a Test Case
  
• Send a GET request to https://prestaging.testsigma.com/api_private/applications/<AppID>.

Expected Results: The request should be successful, and the response must contain the correct info of the app.

Verification:

• Verify the response status code is 200.
  
• Verify the response body to ensure it contains the expected data.

Invalid App ID

Prerequisite: There is no application with the specified <AppID> in the system.

Steps:

• Create a Test Case
  
• Send a GET request to https://prestaging.testsigma.com/api_private/applications/<InvalidAppID>.
  

Expected Results: The request should fail with a 404 status code, and the response must mention invalid app ID or the app does not exist.

Verification:

• Verify the response status code is 404.
  
• Verify the response body with an error message indicating an invalid App ID.

Unauthorized Access

Prerequisite: The API requires right authorization to access the application data.

Steps:

• Create a Test Case
  
• Send a GET request to https://prestaging.testsigma.com/api_private/applications/ with incorrect authorization.
  

Expected Results:
The request should fail with a 401 status code, and the response should indicate that the token is missing or the access is unauthorized.

Verification:

• Verify the response status code is 401.
  
• Verify the response with an error message TOKEN MISSING.