search

pact-foundation / pact-specification

Describes the pact format and verification specifications
MIT License
295 stars 28 forks source link

Multiple providers with shared consumers #41

Closed ma499 closed 4 years ago

ma499 commented 7 years ago

In our platform we have the concept of an 'adaptor' microservice to intermediate between each 3rd party providing the same capability. All adaptors are required to provide (shared) consumers with a consistent external contract - the mapping to each 3rd party is then isolated within each adaptor.

What's the best way of using Pacts to test the same contract against each adaptor? Our initial ideas are below.

  1. We could make our consumer Pact tests aware of each producer (adaptor). The tests could iterate through each adaptor, generating multiple Pact files, or we could modify the Pact implementation to generate multiple identical pact files given an array of producers. This has the downside that we have to modify our consumer(s) source (albeit trivially) when we add a new adaptor. Not great as we want to scale to ~200 3rd parties.

  2. Use something other than Pact. We could validate the adaptor against our Open API spec, potentially as part of run-time monitoring. In that case we would then run consumer Pacts only against a stub or template implementation of our adaptor, which is auto-generated from our Open API spec.

Any other ideas?

uglyog commented 7 years ago

Atlassian have built a tool that can verify pact files against a swagger (or Open API) spec. See https://bitbucket.org/atlassian/swagger-request-validator

bethesque commented 7 years ago

At a scale of 200 consumers, I don't think pact is the best option. Its purpose is to allow the consumers' requirements to drive the provider implementation, and to allow rapid changes with confidence to the provider, avoiding the traditional versioning approach. It's sweet spot is internal APIs. With 200 consumers, you're basically a public API, and you're going to have to provide stable versions, and move at a slower pace because there's no way 200 codebases will be able to keep up with rapid change. Driving out the requirements will be more of a long winded people process rather than a "lets have a quick chat and whip up a potential contract" kind of process.