I could not get it at 20:10 So In the provider's contract tests is okay to Hardcode the data to satisface a consumer contract but we need to create another functional test where the provider's handler output is the Hardcode mentioned before?
@tamashumi7961
8 ай бұрын
Yeah weird, right? If the provider response is hardcoded, then it doesn't address the problem which pacts are meant to address - only moves it. You'd need another contract test between the hardcoded response and actual response to have confidence their structure match.
@Shakor77
Жыл бұрын
I don't get it why optional attributes are not supported. It is quite natural that you have that in a response. For example a json response could return an array of objects and for some objects a certain field is set and some other objects it is not set. This does not mean that I "dont have control of the response" but just that the response is naturally like that and I want it to be like that because that is how the business rules are, which generates the JSON response. To say that Pact test is then not suitable for that I would say is the same as saying that most scenarios, involving complex JSON objects, are not suitable for Pact testing.
@PactFlow
Жыл бұрын
See docs.pact.io/faq#why-is-there-no-support-for-specifying-optional-attributes for why Pact doesn't support optional attributes. We understand in the real world data is modelled in complex ways, but we need to be able to provide guarantees. This is hard to do if we haven't tested each case explicitly. Pactflow's bi-directional contract testing supports this sort of schema check (docs.pactflow.io/docs/bi-directional-contract-testing/) however because of that type of test, the guarantees aren't as strong. This is why we have both offerings.
Пікірлер: 12