foreword
Contract testing, as I stated in Testing Web APIs, is a technical solution to a people problem. Ideally, if teams communicate regularly with one another, the risk of failing integrated systems would be mitigated. But ideals aren’t always the same as reality. We have seen a shift from monolithic products to distributed platforms that see us responsible for potentially hundreds of integrated services. We work in organizations that have embraced remote working or global workforces, creating more disconnected workforces that face new challenges in communication. A testing strategy has to be sensitive to these context changes, and that is why contract testing has become necessary.
I see contract testing as a tool to aid teams: to help facilitate conversation and increase a team’s confidence in developing products in an agile way. Whether you are the consumer of a service or the provider, having contract testing in place eases the fears of making risky changes. Integrations between services change—they have to in order to grow and develop a platform’s features. But with robust contract testing in place, those changes can be rigorously tested early enough in a pipeline to not only catch potential bugs but also enable teams to have the necessary conversations to bring both consumers and providers in line with one another.