https://pact.io logo
Join Slack
Powered by
i tried using valueBoolean = MinType( true,0) but ...
# pact-net
s
i tried using valueBoolean = MinType( true,0) but 0 is not allowed and throwing exception
m
howtooptional
s
m
for the same reason as above, we can’t have a min of 0. If in all of the tests an empty array was returned, we have no confidence that your consumer can handle any of the objects that come back
s
ok thanks , let me go through the link
did not help much ,
"extension": [ { "url": "http://xyz.com/fhir/v1/StructureDefinition/schedulable", "valueBoolean": true }, { "url": "http://xyz.com/fhir/v1/StructureDefinition/serviceOrganization", "valueReference": { "reference": "Organization/Organization-Dept-1", "display": "myDepartment" } } ]
this standard FHIR data and i need to verify valueReference attribute , i can ignore valueBoolean, but how to achieve
m
Each item in the array must be the same shape. So with the current marchers in .NET you can't achieve this without using provider states, and only ensuring an object with the right shape matches each scenario. Alternatively, raise a feature request for the 
arrayContaining
matcher
t
usually when you want to say "this array may contain X or Y" you're suffering from the optional problem - pact doesn't let you say that fields are optional, on purpose - because your consumer either needs them or it doesn't. If you need this, be careful that you're not testing two response types at once. Pretty much the only use case I'm aware of for 
arrayContaining
is where you want to treat an array as an unordered set.
The reason you can't say 
eachLike(X or Y)
is that the array 
[X,X]
or 
[Y,Y]
would both pass the test. Usually you want to be explicit - and expect exactly 
[X, Y]
m
I think the issue here is Tim that some APIs must return a list of heterogenous objects - in this case, because it’s an API standard it doesn’t make sense for the provider to be able to send either X or Y during test based on a state, because the standard doesn’t allow for it.
The 
arrayContaining
feature says “you can send me a bunch of objects, but I only care about X and Y shaped ones”. When the verification runs, the provider can return a bunch of objects, but must have at least X and Y in it, with the appropriate matching rules.
A good example of this are hypermedia APIs such as HAL or Siren, that can have different links and relations in them.
The reason you can’t say 
eachLike(X or Y)
is that the array 
[X,X]
or 
[Y,Y]
would both pass the test. Usually you want to be explicit - and expect exactly 
[X, Y]
On this, I was thinking last night that theoretically we could cover this situation. Currently, each interaction is stateless as far as the framework is concerned (sort of). But could we not wait until the end of the test run and say “wait, you only covered the 
X
scenario but haven’t covered the 
Y
one - we’re not confident your code can do that” type thing? It’s a departure from the model, but I think would allow for this and the other optional field problem to be solved
s
extension = new[] { Match.Type( new { url = "http://xyz.com/fhir/v1/StructureDefinition/schedulable", valueBoolean = true, }), Match.Type(new { url = "http://xyz.com/fhir/v1/StructureDefinition/serviceOrganization", // valueBoolean = Match.MinType("true",0), valueReference = new { reference = "Organization/Organization-Dept-1", display = "myDepartment", } }) },
this worked for me
verified it as well by failing it by changing valueReference to valueReferences
atleast it is verifying the structure
t
Yes, this is verifying exactly that structure. So, if the provider is returning exactly an array with the payload you mentioned here https://pact-foundation.slack.com/archives/C9UTHV2AD/p1661769041018449?thread_ts=1661767040.580199&cid=C9UTHV2AD , then your test will pass.
This is a common pattern for pact, and usually you control the response with provider state
s
yes , these are complex medical\healthcare data , which is hard to create using provider state (requires multiple tools and technologies to create data automatically ) , so we use actual deployment (we have it all automated) and create actual clinical data (production like ) using automation
9 Views
Open in Slack
PreviousNext
Powered by