Open DerManoMann opened 6 years ago
This has been thought about, but the problem is that it doesn't help with generating bodies. If you only provide some paths which point to fragments of the body, how can you generate a full body that would be correct.
Hmm, if you specify alternatives, obviously all would be valid as far as the pact is concerned. I agree, there are cases even in the data I a dealing with where certain variations are restricted and depend on other properties. But that is application logic to me.
The point is that it doesn't stop with the pact - the deserializer faces the same issue and you certainly need a solution for that - in my case I have to deal with that in both PHP and Java and each language has libraries that support this - irrespsective of whether the combination of different sub types is valid within the business logic... Its actually quite simple to annotate an Interface and then provide some custom code to the deserializer to decide which implementation model to use.
Example:
{
"subject": [
{
"type": "bike",
"colour": "red"
}
]
"action": "replace chain"
}
vs.
{
"subject": [
{
"type": "car",
"colour": "blue"
}
]
"action": "fix clutch"
}
So, subject
can be multiple things, but in the context of the action only one is valid. However, to me that is not part of the pact to validate, but something unit/integration tests should do.
Hi there, In our JSON models we do have a fair number of unions - arrays of objects with different structure. In order to cover all cases it seems we'll need to create a matrix of test data since there doesn't seem to be support for path selectors.
Is this something considered in V3 or something that could be implemented in a custom matcher?