Contract testing

When you want to ascertain the validity of the responses sent from a server to the requests by a client in a system under test, you can define a schema for the expected messages, and then the incoming messages can be validated against the defined schema for adherence to a contract. You can create Contract tests in Test Integrations and APIs that validate the schema in the incoming messages for conformance with the schema defined for the messages.

Overview

Contract testing is a testing methodology to ensure that services between an API provider or a server and an API consumer or client can communicate with each other. In this methodology the consumer and the provider agree by means of a contract to communicate with each other.

The following types of Contract testing are supported in Test Integrations and APIs:
  • Producer-driven Contract testing
  • Consumer-driven Contract testing

In both types of testing, Test Integrations and APIs supports the defining of a schema for the messages and then validating the schema in either the incoming or outgoing messages as an adherence to a contract.

Consumer-driven contract testing

Consumer-driven Contract testing can be used to ascertain if the responses sent by a producer (a server in the system under test (SUT)) to a consumer (a client in the SUT) are the messages that are expected by the consumer for the requests sent. Test Integrations and APIs is enabled to validate the schema and the roots in the schema in the incoming messages to conform with the schema and roots defined for the expected messages as a validation of the contract initiated by the consumer.

To perform consumer-driven Contract testing in Test Integrations and APIs, you must configure the MEP for an operation. You must select the schema and the roots in the schema for the outgoing messages in the Subscribe or Reply action in the MEP. You must create a contract test in the Test Factory view. The test checks and validates the roots and schema defined in the Subscribe or Reply action and the test passes when the contract validation is passed.

Task flow for consumer-driven contract testing

The following table provides a list of the tasks that you must perform for testing consumer-driven Contract tests. You can also find the link to the corresponding topic for the details of the task.
Task More information
1. You must create a project. Creating a project
2. You must create a logical resource and bind it to its corresponding type of physical resource. The Logical View
Note: Refer to the tasks to create logical resources from the list of supported resource types in Table 1.
3. You must create a service component under the logical resource. Creating a service component
4. You must create an operation under the service component. Creating an operation
5. You must add a schema that is used to validate the incoming messages. Adding a schema
6. You must configure the Message Exchange Pattern (MEP) settings for the operation. Configuring the MEP settings to create consumer-driven Contract tests
7. You can create the following types of consumer-driven Contract tests:
  • A single consumer-driven contract test.
  • Multiple consumer-driven contract tests.

Consumer-driven Contract tests creation

After you have configured the MEP for the operation, you can create the following types of consumer-driven Contract tests:
  • A single Contract test.
  • Multiple Contract tests.

You can create different consumer-driven Contract tests for each of the content configuration or the variable test data that you set by selecting the Fixed option when creating multiple Contract tests.

Alternatively, by selecting the Data Driven option, you can create multiple data-driven Contract tests that depend on the structure of the schema defined for the messages and the content combinations that you specify. Either of the following results can occur:
  • A single data-driven Contract test with multiple content iterations is created along with the test data in an Excel worksheet that specifies the values for the iterations which is used at test run time.
  • Multiple data-driven Contract tests with different test structures and content iterations along with the test data in different files that are used by each of the tests during test run time.

Producer-driven Contract testing

To perform producer-driven Contract testing in Test Integrations and APIs, you must configure a producer in an operation and create tests based on an MEP. You must add a schema for the messages in the Publish or Request action in the MEP. You must then create a stub that has a Message Case under a Message Switch action. The Message Case receives or subscribes to the incoming messages sent as the Publish or Request action in the tests. You must select the Include Contract Validation option in the stub properties tab. When the stub is run followed by the test, the incoming messages are validated for adherence to the defined schema as a contract and a response sent to the test.

Task flow for producer-driven Contract testing

The following table provides a list of the tasks that you must perform for testing producer-driven Contract tests. You can also find the link to the corresponding topic for the details of the task.
Task More information
1. Create a project. Creating a project
2. Create a logical resource and bind it to its corresponding type of physical resource. The Logical View
Note: Refer to the tasks to create logical resources from the list of supported resource types in Table 1.
3. Create a service component under the logical resource. Creating a service component
4. Create an operation under the service component. Creating an operation
5. Add a schema that is used to validate the outgoing messages. Adding a schema
6. Configure the Message Exchange Pattern (MEP) settings for the operation. Configuring the MEP settings to create producer-driven Contract tests
7. Create a test under the operation. Creating a single test by using MEP or Creating multiple tests by using MEP
8. Create a message-based stub under the operation. Creating a stub by using MEP
9. Edit the stub. Editing message-based stubs for Contract validation

Synchronizing resources to generate Contract tests and stubs

When you already have created tests in another application for your system under test and you have defined schemas and roots for messages, you can use the synchronizing feature of Test Integrations and APIs to generate Contract tests along with stubs that you can run on Test Integrations and APIs. You can opt to generate Contract tests along with stubs during the synchronizing process.

When you want to test for consumer-driven Contract tests by synchronizing resources, see Creating consumer-driven Contract tests by synchronizing resources.

When you want to test for producer-driven Contract tests by synchronizing resources, see Creating producer-driven Contract tests by synchronizing resources.

Benefits of running Contract tests

When you run consumer-driven Contract tests on Test Integrations and APIs, you are able to ascertain the validity of the requests sent by the consumers.

You can run tests on stubs to validate contracts for adherence to the defined schema in messages sent by producers.