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
This issue is similar to #354 and apologies for my duplicated comment.
The API I am looking at testing with Spring Cloud Contract has multiple non-primitive optional request fields, and when certain optional request fields are provided then certain optional fields are conditionally returned by the API.
This seems difficult to model in Spring Cloud Contract. I can see a few options and each of which has some downsides.
Do not include the optional attributes in the contract. The downside of this is that the contract covers less. If there are a large number of optional fields, then the contracts aren't that expressive as they cover a small number of fields.
Create additional contract scenarios which cover the optional fields. The problem with this approach is that you can end up with a large number of contracts scenarios (just for the success cases) and this has a few downsides:
multiple contract scenarios can match a request - then you need to use something like priorities to preference one contract over another one.
if there are multiple scenarios there can be duplicated parts of the request between the scenarios which isn't ideal. An issue could get fixed in one contract scenario, but remain in other scenarios.
slower to run the stub runners when there are a large number of scenarios.
If optional complex object is not a feature on the radar for the project, then how would people typically handle testing for this type of API? Any recommendations or advice is appreciated.
The text was updated successfully, but these errors were encountered:
This issue is similar to #354 and apologies for my duplicated comment.
The API I am looking at testing with Spring Cloud Contract has multiple non-primitive optional request fields, and when certain optional request fields are provided then certain optional fields are conditionally returned by the API.
This seems difficult to model in Spring Cloud Contract. I can see a few options and each of which has some downsides.
Do not include the optional attributes in the contract. The downside of this is that the contract covers less. If there are a large number of optional fields, then the contracts aren't that expressive as they cover a small number of fields.
Create additional contract scenarios which cover the optional fields. The problem with this approach is that you can end up with a large number of contracts scenarios (just for the success cases) and this has a few downsides:
If optional complex object is not a feature on the radar for the project, then how would people typically handle testing for this type of API? Any recommendations or advice is appreciated.
The text was updated successfully, but these errors were encountered: