By Seb Rose
The rise of micro-service architectures offers the promise of a more agile software development process. Software systems will be made up of many collaborating components which are developed, deployed and operated by distributed teams and organisations.
But how can we avoid a recurring configuration nightmare (c.f. DLL hell) and ensure that we benefit from the promised flexibility, rather than creating a fragile, distributed monolith? Contract testing with Pact offers an excellent solution.
The rise of micro-service architectures holds the promise of a more agile software development process. Software systems will be made up of many collaborating components which are developed, deployed and operated by distributed teams and organisations. But how can we avoid a recurring configuration nightmare (c.f. DLL hell) and ensure that we benefit from the promised flexibility, rather than creating a fragile, distributed monolith?
One approach is suggested by the test automation pyramid, which suggests that we favour unit and integration tests over end-to-end tests, which leads developers to use test doubles (fakes, stubs, mocks etc.). The risk is that the developer’s test double does not behave in exactly the same way as the actual component that it is replacing. When this happens, the tests all pass in your build pipeline, but you get failures when it’s released into an integration (or production) environment.
Contract testing is a technique that can give you confidence that your test doubles are accurately simulating the dependencies that they replace. This is not a new technique, but the extra investment in creating and maintaining (yet another) suite of tests has restricted its uptake. Instead, organizations mitigate the risks by investing in more and more integration environments and end-to-end tests. This was always expensive, but with the adoption of micro-service architectures across the industry, the cost and complexity has escalated to a point where this approach is no longer sustainable.