You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Single element: Pact doesn't support it to be optional. This is nothing new. If we really want to test optional behavior, on consumer, we need to write 2 tests:
Element is null
Element match something
Array of elements/A map: The FAQ said it's not supported, but we can achieve it in many ways:
atLeast, atMost, constrainedArrayLike
Validate min on consumer, then force setting min >= 1
Pact-GO does this
But Pact-JS or Pact-PHP doesn't do this (I'm not sure about other languages)
There are absolutely nothing stop user from bypassing this validation. User just learn how Json Integration works, then write the syntax by themself (which has min=0, like this Validate min = 0 #304).
There are nothing we can do to stop provider to return empty list/map
matchAll
If consumer doesn't add atLeast(), or just add atLeast(0), there are nothing we can do to stop provider to return empty list/map
values
This matcher is weird (and deprecated in Pact-PHP), so I prefer don't talk about it.
So, it's hard to handle empty list/map on consumer side. How about we do this while verifying provider:
When verifying, if provider return empty list/map, and somehow it match all the rules (describe above), we display a warning like this Empty list/map is very risky. It's suggested to return non-empty list/map to verify its structure
The text was updated successfully, but these errors were encountered:
This idea is related to Optional Attributes
atLeast
,atMost
,constrainedArrayLike
min
on consumer, then force settingmin >= 1
min=0
, like this Validatemin = 0
#304).min=0
in FFI Validatemin = 0
#304: @rholshausen doesn't agree with it, and I also don't agreeeachKey
,eachValue
matchAll
atLeast()
, or just addatLeast(0)
, there are nothing we can do to stop provider to return empty list/mapvalues
So, it's hard to handle empty list/map on consumer side. How about we do this while verifying provider:
When verifying, if provider return empty list/map, and somehow it match all the rules (describe above), we display a warning like this
Empty list/map is very risky. It's suggested to return non-empty list/map to verify its structure
The text was updated successfully, but these errors were encountered: