Pact has been growing in popularity and is now the de-facto contract testing framework—the new industry standard approach to testing distributed systems, such as microservices. Organisations of all sizes are displacing end-to-end integrated testing with consumer driven contract testing as the cornerstone of an integration testing strategy.
You’ll be familiar with the benefits of consumer driven contract testing however there are some drawbacks which mean some organisations will experience slower time-to-value, may have to resort to alternative testing solutions, or run into issues when scaling to very large teams and systems. This is why we created Bi-Directional Contract Testing.
Here’s a summary of the differences between consumer driven contract testing and Bi-Directional Contract Testing:
| Using consumer driven contract testing | With the addition of Bi-Directional Contract Testing |
|---|---|
| Consumer driven contract testing has a steep learning curve. | Bi-Directional Contract Testing is conceptually much simpler to understand, and looks more like the kinds of testing teams are used to doing today. |
| Consumer driven contract testing (with Pact) requires you to learn a new testing framework. | Bi-Directional Contract Testing works with ecosystems such as OpenAPI and tools such as Wiremock, Cypress, Postman or Dredd, reducing the need to learn a new framework, and taking advantage of the rich tools already in the market. |
| To get up and running with consumer driven contract testing, technical investment is required. | By leveraging existing tools and processes already in place in your organisation and “upgrading” them into a contract testing workflow, Bi-Directional Contract Testing feature helps teams decrease the time to value and rapidly scale contract testing coverage across their systems. |
| Consumer driven contract testing requires access to the code meaning some roles cannot contribute easily. | With Bi-Directional Contract Testing , contracts can be captured and verified without direct access to the code base, enabling broader role participation – such as Testers and QA Engineers – to take part in contract testing to ensure quality, together. |
| Consumer driven contract testing is not ideally suited to working with API gateways, 3rd party APIs or APIs with large numbers of consumers. | Bi-Directional Contract Testing doesn’t require the same level of coordination between consumer and provider teams as traditional Pact testing, enabling these additional use cases. |
| Consumer driven contract testing is not suited for API first design workflows. | With Bi-Directional Contract Testing the provider side can publish their contract as soon as it’s ready, and no longer needs to wait for the contract to be initiated by the consumer of the API (and vice-versa). You can choose the workflow that works for your organisation. |
| It may be difficult to convince others of the benefits of consumer driven contract testing. | Put simply: we’ve removed the most common objections to implementing contract testing we’ve heard over the past two years of running Pactflow. |
The other major difference is that Bi-Directional Contract Testing is available exclusively to Pactflow customers.
Ready to learn more about this feature? Visit the Bi-Directional Contract Testing docs.
