There is some Fear, Uncertainty and Doubt around contract-testing. Don’t be afraid on new techniques but do learn how to use them appropriately . You absolutely do not mock out both ends that would be an anti pattern.
Contract Testing is a very useful and well proven technique for adding assurance that two (or more) services continue to be compatible without having to deploy them both at the same time for integration or e2e testing.
The idea has been around since the 1980’s but has become popular with growth of microservices and release of “pact .io” in 2013.
A challenge with microservices is that it can become prohibitively slow and expensive to deploy very large numbers of services to multiple test environments. Also you want to enable teams to operate in parallel, team A might be creating a service dependent on team B before team B have finished.
The way it works is by defining a contract between the services. A contract is simply an API endpoint or json schema for a message. This contract can be generated by the provider (provider driven contract-testing) such as swagger/openapi spec or can be specified by the consumer (consumer driven contract-testing) ala pact.
In either case:-
- The consumer, validates it’s code can handle messages following the contract ( this is where mocks are used).
- The provider, validates it’s code only generates messages following the contract. (here a real service is used with matching or schema validation).
- There may also be a broker - which distributes the contracts, and has information about which versions have been tested by both consumer and provider.
So you see both parts get testing but testing is separated. It isn’t quite the same as replaying traffic but it has some similar concepts.
An acute tester will spot the possibility of gaps in the possible variations of messages still meeting the contract. But you can cover a few variations and that possibility also exists for integration testing.
Contract-Testing is also likely to be combined with some targeted integration tests, smoke-checking in production or other risk reduction techniques such as canaries.
So for sure it’s a big change in the approach to testing, and some people feel a loss of control with the lack of e2e testing but control is an illusion and it’s a proven technique which has enabled a number of organisations to succeed.