pact-specification
pact-specification copied to clipboard
Multiple matchers?
The spec for v2 says you can only use one matcher at a time: Regex, Type, MinType or MaxType. But what if you want use MinType and MaxType to guarantee the number of minimum and maximum elements of an array?
What is missing (and has been raised in forums before) is a MinMaxType matcher. I've added support for this in Pact-JVM, but it is currently undocumented and not supported by any DSL.
I'm going to update the V3 spec to include this.
@OliverSanftleben can you explain the reason for such a restriction? I'd like to understand the use case better. How does it help you test the format of the messages between a consumer and provider? Are you trying to test the functionality of the provider, rather than the contract?
@bethesque For example the consumer asks for a list, which should have at least one element, but should have a maximum of 30 elements like with paging.
GET /list?rangeFrom=1&rangeTo=30 GET /list?rangeFrom=31&rangeTo=60
and so on...
That sounds like a functional test @OliverSanftleben. The typical example for min/max are things where the numbers actually have semantic meaning (in your case, it's a filter on the API which is more of an operational thing).
e.g. Sometimes GPS coordinates are represented as an array like [123.45, 456.78]
, where it must be exactly 2 integers.
@OliverSanftleben please read this https://docs.pact.io/best-practices/consumer/contract-tests-vs-functional-tests
Short answer - the assertion you're trying to make belongs to a test in the provider's codebase. It's not the job of the consumer to test the provider. What you should be doing is ensuring that the consumer and provider have a shared understanding of the messages that will pass between them.
If you're concerned about making sure that you are specifying the range using the correct parameters, I'd recommend reading this: https://docs.pact.io/best-practices/provider/using-provider-states-effectively
@bethesque Ok, but the example with the GPS coordinates is also remarkable. I have also GPS coordinates in my data.
I used that example as I've seen that notation before. As an aside, I would still prefer the use of an object with keyed values (to avoid misinterpretation of which value is a lat/lng)