Contract testing is a method for verifying the integration of systems by individually examining each application to confirm that contracts and interfaces adhere to the mutually agreed upon terms.
A mock integration point enables the confirmation of a component’s expected behavior without dependence on that component. In a large and intricate application, a trusted integration point may be required by multiple applications. This trust ensures that the integration point’s behaviors are validated by all dependent applications, safeguarding the system from unintended or harmful changes. Thus, a system can be constructed where each component performs a specific task, and the system is protected from accidental or malicious alterations to any component.
What are the advantages of utilizing contract testing and why is it a preferred choice?
Contract testing is a highly effective technique for:
- Identifying irregularities in consumer workflows and addressing them at early stages
- Detecting service configuration defects that may impact inter-application communication
- Ensuring secure connections even when producers make changes to service configurations, providing guarantees to data consumers
- Allowing producers to perform their tasks without disrupting consumer workflows, which is particularly beneficial during regression testing
- Giving consumers the flexibility to define their requirements and consume only what they need
- Preventing unexpected API communication failures through the use of local or mock implementations, which are more stable, faster, and reliable during the application testing phase
- Facilitating rapid issue detection and resolution
Under what circumstances is contract testing not recommended?
It is important to consider both the advantages and disadvantages before making a decision.
Here are the main instances when contract testing may not be appropriate:
- Contract tests are not intended to replace Unit or Functional (component) tests
- Contract tests should not be used as a substitute for other types of tests
- If there is little or no communication between teams where contract tests are being set up, this can result in an unreliable and untrustworthy contract
- Using contract tests simply because they provide an additional layer of test coverage or because they are a new and trendy technique is not a valid reason and will not add value to your test flows
- Before making any decisions, it is important to evaluate the business value, estimated time of arrival for implementation, and consider the minimum viable product that can be provided and presented. It is also worth noting that integrating new features or tools requires workshops to onboard teams and users
Where do contract tests fall within the testing pyramid hierarchy?
For a more detailed view, let’s examine the following table:
What are the available tools and options for contract testing?
There are a limited number of battle-tested and production-ready tools available for implementing contract testing. Some options include:
What factors should be considered when selecting the most suitable contract testing tool for your project?
A brief overview of the capabilities of each tool can aid in making an informed decision:
What are the default approaches or workflows utilized by each tool and how do they differ from one another?
Let’s examine the characteristics of producer-driven contract testing.
In a producer-driven approach, the producer generates contracts and passes them on to consumers.
Let’s delve deeper into the workings of the Spring Cloud Contract tool and explore its behind-the-scenes operations.
Let’s now examine the workflow of consumer-driven contract testing.
The following image depicts the functionality of Pact
How to establish a new contract?
Add new contract
- Create a new contract
- Store the contract in the contract repository
- Conduct a review of the contract
- Develop consumer-side tests
- Develop producer-side tests
- Integrate the contract into the codebase
- Integrate consumer-side tests into the codebase
- Integrate producer-side tests into the codebase
Update existing contract
- Modify the existing contract
- Store the updated contract in the contract repository
- Conduct a review of the updated contract
- Implement changes on each consumer’s side
- Implement changes on each producer’s side
- Integrate the updated contract into the codebase
- Integrate changes on the consumer’s side into the codebase
- Integrate changes on the producer’s side into the codebase
When Should Contract Tests be Executed? Integration into the Development Pipeline
- Build Phase:
- Compile the code
- Generate contract files
- Test Phase (conducted in parallel):
- Execute unit tests
- Run integration tests
- Perform contract tests (consider implementing a safe failure backup plan for quick production deployment during incidents)
- Conduct other automated tests
- Deployment Phase:
- Deploy the code to the production environment
Conclusion
In this piece, we delved into the concept of contract testing, weighing its advantages and disadvantages, and provided insights to aid in making informed decisions.
Next Steps
In the following article, we will demonstrate how to construct a highly scalable solution utilizing pipelines from GitHub or GitLab.
Top comments (1)
Not seen much of Contract testing before, great write up, thank you for sharing