Hey everyone! I have a consumer contract test wher...
# general
j
Hey everyone! I have a consumer contract test where I want to reflect that we expect an array with at least one element containing a boolean with value true. From the forums and docs, I understand I can use "*arrayContaining*" to reflect this. I have two questions regarding this: • I actually want to say we want only one element to have this boolean true, all other elements must have it as false. But I believe this is not possible to reflect? • The bigger problem, is that I don't know how to use this "arrayContaining" in the DSL, while it seems to only be possible on arrays contained within an object. The event structure we are consuming is however containing an array on top level, so no parent object. And it is this array which has this requirement. I hope my problem is understandable, and that someone could help out 🙂 I am using Pact JVM btw
m
For questions on syntax, probably best bet is asking in #C9UN99H24
but on this
I actually want to say we want only one element to have this boolean true, all other elements must have it as false. But I believe this is not possible to reflect?
why does it have to be this way? (I’m asking to make sure you’re not enforcing a strict/unnecessary contract on a provider)
j
Hi Matt - We will choose the one element of the array which has the value set to true, and this contains the data important to us which we need in the rest of the flow triggered by this event. Without this one element, the event is useless to us. Should this then not also be reflected in the pact?
b
Bringing that to a more philosophical design perspective, maybe there's a different data structure that represents that concept better? (not to say that you should refactor everything, but a less error-prone data design could also make it easy to specify in the contract, if that's your desire)
☝️ 1
e.g. a field at the top level (outside the list) that means "ID of the element that would've had a "true" value in that field" Then you avoid the chance of multiple elements having the "true" value, and a smaller footprint in the body to check for correctness.
m
Yep. I’m also not so keen on enforcing constraints on other values that aren’t relevant to the consumer. This seems like it could easily end in a situation where another consumer may have conflicting needs.
j
Unfortunately, the definition of the schema for the provider is out of my team's control. I am now wondering if trying to enforce this case is out of scope for the contract tests - and maybe it does go in the direction of trying to test functional requirements, which I believe is not the point with these tests. Maybe it is enough to say the boolean attribute is mandatory with any boolean value, at least that is how it is defined in the schema. Thanks for your input!
👍 2
m
You're welcome!