Contract testing is a method for verifying the integration of systems by individually testing each application to ensure that contracts and interfaces adhere to the agreed-upon specifications.

A mock integration point enables the validation of a component’s expected behavior without relying on the actual component. This is particularly useful in large and complex applications where multiple applications rely on a single, trusted integration point. By validating the behaviors of the integration point, accidental or malicious changes can be prevented from affecting the overall system.

Why choose contract testing?

Contract testing offers several benefits, including:

• Early detection of irregularities in consumer workflows

• Identification of service configuration defects that may impact inter-application communication

• Protection of connections even when service configurations change

• Prevention of disruptions to consumer workflows when producers make changes

• Freedom for consumers to define their requirements and consume only what they need

• Reduction of API communication failures through local or mock implementations during testing

• Faster issue detection and resolution

When not to use contract testing?

Contract testing is not always the best choice. It should not be used as a replacement for unit or functional tests, nor should it be used without proper communication between teams. Additionally, it should not be adopted simply because it is a new technique or provides another layer of test coverage. Before implementing contract testing, it is important to consider the business value, estimated time for implementation, and minimum viable product. Onboarding teams and users through workshops may also be necessary.

In the context of the testing pyramid, where do contract tests fit in?

For a more detailed view, please refer to the table below:

What tools are available? What are my choices?

There are a limited number of tools available for implementing contract testing that is robust and ready for production:

• Pact

• Spring Cloud Contracts

Which tool is the best fit?

Factors to consider when selecting the appropriate tool for your project A brief overview of what each tool offers to aid in making an informed decision:

What are the default methods or processes used by each tool? How do they vary?

Let’s examine the producer-driven contract testing approach.

In a producer-driven approach, the producer generates and shares contracts with consumers.

Now, let’s delve deeper into how the Spring Cloud Contract tool operates and what happens behind the scenes.

Now, let’s examine the consumer-driven contract testing approach.

The following image depicts the functionality of Pact.

How does one go about creating a new contract?

Add new contract

1. Add new contract to a repository

2. Review contract

3. Implement consumer-side tests

4. Implement producer-side tests

5. Merge contract and tests

Updating existing contract

1. Updating the contract in the repository

2. Reviewing the contract

3. Applying changes to consumers and producers

4. Merging changes

When should contract tests be executed?

Integration into the development pipeline includes:

1. Build phase: build code and generate contracts

2. Test phase: perform unit, integration, and contract tests in parallel (consider a backup plan for quick production deployment during incidents)

3. Deploy to production

Conclusion

This article explains contract testing, its advantages and disadvantages, and how to make informed decisions.

Next steps

Let's explore building a scalable solution using GitHub or GitLab pipelines.