Draft:Contract testing

• Comment: Still no good sources to prove credibility. OnlyNano^talk 17:54, 28 June 2024 (UTC)

• Comment: Most of the sources in this draft are not reliable, such as medium (which is not reliable per WP:MEDIUM), and the pactflow.io source is a blog, which is not going to be as reliable. ‍Relativity ⚡️ 21:54, 3 June 2024 (UTC)

---

Contract testing is a type of software testing.

The basic aim of contract testing is to ensure that software modules that communicate by exchanging messages, typically over HTTP or message queues, agree on the form that such messages must adhere to.

Contract testing complements other form of software testing, such us unit testing, integration testing or end-to-end testing. Its main aim is to reduce the amount of end-to-end testing by ensuring that message exchange will be successful. It does not replace end-to-end functional testing as contract testing is only concerned with the form of the exchanged messages and not with the result of processing those messages.

Contract testing entities

Contract testing identifies three participants in the testing flow:

• The Consumer: in a HTTP exchange identifies the module performing the HTTP call. In queue messaging it identifies the consumer of messages from the queue.
• The Provider: in a HTTP exchange identifies the module receiving the HTTP call. In queue messaging identifies the publisher of events to the queue.
• The Broker: a centralised contract testing specific app to which all consumers and provides refer to to store and retrieve the contract files produced during contract testing.

Contract testing approaches

There are three basic approaches to contract testing

• Consumer-Driven Contract Testing (CDCT or CDC): in this approach the Consumer initiates the test flow by mocking the provider and publishing to the Broker the contract file produced during the testing.
• Provider-Driven Contract Testing (PDCT or PDC): in this approach the Provider initiates the test flow by publishing to the Broker the contract it fulfils. Consumers will then verify if they adhere to it.
• Bidirectional Contract Testing (BDCT): in this approach any of the two ends, Consumer of Provider, can initiate the test flow by publishing their version of the contract to the Broker. Once both contracts involved in an interaction have been published, it is the Broker that will verify if they match.

Contract testing flow

A typical flow for testing a HTTP interface in a Consumer-Driven Contract Testing would be:

• The Consumer creates a test where the Provider module is mocked using a contract testing library. When the test is run, the consumer generates the message it intends to send to the producer and defines the responses it expects.
• When the Consumer test is executed, typically during a build pipeline, the contract testing mock library records all HTTP interactions in a file, called "contract", containing all received payloads and expected responses.
• The Consumer pipeline publishes the contract file to the Broker
• The Provider creates a test using a contract testing library which will download the contract from the Broker and replay all interactions contained in the contract against the Provider's HTTP endpoints.
• The Provider communicates to the Broker the outcome of the test indicating if the expected responses for each request in the contract could be produced.

If the Provider reports a success the two modules can be confident that they can communicate over HTTP interface for the endpoints considered in the contract testing.

Typically, the Broker will provide methods to get information on contract verification allowing pipelines to decide if a given version of a Consumer or Provider is suitable for deployment or if the deployment must be halted due a contract mismatch.