You have probably come across this page because:
- You’re considering adopting contract tests in your organisation.
- You are a QA/Dev who has recently been assigned an assignment to implement.
- You’ve heard this buzzword and wondered what all the excitement is about.
- For some reason, the medium algorithm determined that you should read this.
Whatever the cause, this article will attempt to provide you with knowledge of:
- What exactly is Contract Testing, and what are the advantages?
- What position it occupies on the Testing Pyramid?
- When should the Contract test be performed?
- Contract test technical implementation with a link to a git repo
Contract Testing
Contract testing is used to test the ‘understanding’ of two components that communicate with each other and provide rapid feedback between engagements. Contract testing is based on storing the interactions of the two services in a broker. The two service owners must reach an agreement, and any deviations from the agreed-upon interactions will result in a contract test failure.
Contract testing in distributed systems can lessen the need for E2E and eliminate any environmental and infrastructure requirements. Saving time and money on testing and environmental setup.
Benefits of Contract Testing
- Lightweight tests
- Because they are not dependent on the environment or infrastructure configuration and are repeatable, they are particularly cost-effective. - Issues are easy to fix
- Contract tests require extremely little maintenance; if a test fails, it may be reviewed with the concerned team and remedied immediately. - Independent testing
- Independent testing enables each component to be tested in isolation, saving deployment time. - Allows you to shift left.
- Bugs and contract ambiguities can be identified early in the development lifecycle, and tests can be performed locally to catch issues before any pull requests or merges are made.
Testing Pyramid
Getting the time of running contact tests is advantageous since it maximises the value added. Contract tests are run after unit tests and before integration tests, according to the pyramid image above.
The unit tests are the ‘cheapest’ to execute; after that, it is efficient to run the contract tests; if the contract tests fail, the integration and E2E tests will most likely fail as well. Running the contract tests earlier also allows for early feedback in identifying errors, therefore the order of execution is critical in shifting-left effectively
Contract tests can be run automatically as part of a pipeline for each commit and pull request, or they can be run manually in local development.
Failures?!
Each organisation will have its own procedure for dealing with contract test failures
Some argue that, unlike a functional test, a failure in the contract testing should not break or stop the build. The failure might be viewed as an early warning to get things back on track.
Other organisations may have more stringent standards in place to fail the build and mandate a fix on either the consumer or the producer side before the build can be allowed to pass.
This is up to the purview of the QA leaders on within the organisation.
Roles in PACT tests
When dealing with contract testing, there are three main components to remember:
- Consumer: The consumer is the service that sends a request to the downstream service and is in charge of starting the contract testing process, for the consumer driven contract testing, by opening discussions with the provider team. The consumer will publish the pact which will contain the request(s) the consumer will send and the responses they expect.
- Provider: This is the service that will be used by the consumer; the provider side is where the testing happens. If the provider service has introduced a change that violates the contract, the provider should not be allowed to build or package the service. Upon failure, the provider team will be forced to communicate the breaking changes to the consumer, establishing a new contract between the two teams or services and ensuring that no bugs find their way into production. After the new contract has been published by the consumer, the provider service may continue with the development cycle.
- Pact Broker: The Pact contract has to be stored in a ‘neutral zone’ and not in either the consumer or provider repo. This is where the ‘broker’ comes in. The broker ensures full visibility of contracts and test results and provides a central location. The Pact Broker will host the Pact contract published by the Consumer and allow the Provider side to pull the contract during testing.
Example PACT Test Setup
The repo below contains 2 services the consumer and producer.
The consumer service receives a request to retrieve a bank balance (which is currently hardcoded) and sends a request downstream to the provider service to convert the funds into the desired currency.
To run the actual tests the services do not need to be up and running due to the way the tests were built, only the dockerized infrastructure has to be up and running to run the tests.
The validations on the producer side has been designed to fail due to the decimal places being more than expected, if you are up for a challenge fix the provider service to get the test passing.
The shift towards microservices means the Software-Testing-Lifecyle has to eventually evolve away from costly E2E testing, if you feel like implementing PACT testing is the next natural step in your evolution as an individual or an organisation reach out to us on QABound or send us a message on Linkedin
