Multiple providers per client...

[tsfischer]

This is a general PACT question... hope it's OK to ask here:

The product I'm developing has two potential back-end servers (providers). The first is a full-featured one, and the second will implement a subset of the features.

To give a fictionalized example, one of our APIs returns an array of "products". Let's say a product contains a name (string), description (string), and availableCoupons, which is an array of ints, referring to coupons from another API.

However, the lightweight provider doesn't deal with coupons, and will always return an empty array here.

When the consumer creates the contract, I gave it mock data with "products" which have examples both specifying and not specifying 'availableCoupons'. However, our provider (server) folks from the lightweight server say that they cannot fulfill this contract, since they don't have a means to return coupons.

What is the proper PACT-ful way to incorporate this? I can use separate tests, one with coupons specified, and the second without, and only have the lightweight server have the one without as part of their contract... but that seems wrong, since they're not violating the contract, they're just not fully implementing it.

Thoughts?

[surpher]

Of course it is okay, though best place for general Pact questions is the Slack community where all sorts of different set ups are discussed.

In PactSwift you can allow empty arrays as valid responses by using EachLike matcher with min: 0. This would require availableCoupons key of defined specific Type to be present in the response but if it is an empty array, it is fine as mock server would not verify for Type (it is an empty array 🤷‍♂️ ). And consumer can test against the provided value because it is set during the consumer tests. This way the provider would be able to validate successfully even if an empty array is always returned, as long as the availableCoupons key is in response.

let body: [
  "products": Matcher.EachLike(
     [
       "name": Matcher.SomethingLike("foo"),
       "description": Matcher.SomethingLike("bar"),
       "availableCoupons": Matcher.EachLike(Matcher.IntLike(1234), min: 0) // <-- demand the `availableCoupons` to be present in response but allows an empty array and should pass the provider validation
     ],
     min: 1, // <-- expect at least one product in response when validating provider 
     max: 999, // <-- allow max 999 products in response
     count: 5  // <-- mock server returns 5 mocked products for consumer to test with
   )
]

I hope I understood your question.

[tsfischer]

Thanks for the response. I was under the impression "min" could not be zero in this case. For example, the EachLike docu says that min (and max) must be positive.

[tsfischer]

To clarify... the second provider will never fill out the "coupons" array, because it doesn't have that capability. Does that mean I can never have test data in the contract that shows that array filled?

[surpher]

Ah, I'll update the documentation. Thanks for pointing it out. And yes, it can be 0 or positive value.

You can have test data in there if you want to test your consumer code. But if the contract is set up requiring at least some value in there, then provider will never be able to verify successfully. That's why, if you accept that discrepancy, you can set up your consumer tests with data, and set the min: 0 to allow providers to return an empty array.
If the provider will not even return an empty array, then the consumer is requesting too much and should not put the coupons in the contract.

On the other hand, you could/can have two separate tests for different states and the providers set up their verification in such a way to ignore the test with the specific state.

func testProviderAReturningCoupons() {
given(Provider has coupons functionality)...
// setup to return an array with non-zero array
}

func testProviderBNotReturningCoupons() {
given(Provider does not have coupons functionality)...
// setup to not even return the `coupons` key
}

Provider side, hopefully using the Pact implementation capable of filtering the states, can then filter depending on the test.

Another way to go about this is have separate contracts just for this situation. And providers verify against two contracts. They would setup two tests to verify against "supportedContract", and another for "specificNonSupported". Providers are able to define what contracts on the Pact broker they should validate against.

An example with PactSwift, providers can define the providerName when fetching contracts from Pact broker. If you had two contracts for these specific cases they could set up the two unit tests on provider side verifying separate contracts.
Let's say you could have two contracts with provider names eg providersForFeature and secondProvider-noCoupons and the providers would setup their tests depending on the contract and interactions the contracts contain.

[tsfischer]

Thanks for all the great info, I'll give this a try