https://pact.io logo
Join Slack
Powered by
Hello, I got the following feedback from a teammat...
# pact-jvm
é
Hello, I got the following feedback from a teammate
Hi there!
A small issue we just encounter with PACT. Our PACT consumer is green and was validated by the provider, so all seems good. But then, when we did our first test and we are facing a deserialization issue on the provider side. After investigating, the consumer is not serializing in the right way an enumeration value. The provider is expecting "`customer_order`" and the consumer is sending "`CUSTOMER_ORDER`".
So I did some test on the consumer, to understand why this has not broken the PACT on the consumer side. And it seems that the PACT consumer will broke if an expected field in the request is missing, but not if the values does not match... I am a bit sad about this behavior, I was expected the PACT to fully validate the body, field and value. This mean, we need to write additional integration test to validate the serialization of the consumer, not cool 😕! Or maybe we are missing a configuration somewhere? I haven't found something yet
His solution was to implement a matcher on the request field.
Copy code
.stringMatcher(
            "issuer_type",
            "^("
                + Arrays.stream(IssuerTypeDTO.values())
                    .map(IssuerTypeDTO::getCode)
                    .collect(Collectors.joining("|"))
                + ")",
            IssuerTypeDTO.CUSTOMER_ORDER.getCode())
I'm aware that Pact is not strict in the response's value but was expecting more control on the request content as per Postel's Law. Should
m
No, Pact should detect this situation. There is some other issue going on
And it seems that the PACT consumer will broke if an expected field in the request is missing, but not if the values does not match
In the consumer test, it won’t fail when the unit test happens if the response value is incorrect (it’s a mock of the provider at this stage, which has yet to be verified).
At this point, if you are using 
can-i-deploy
, this check should not pass, because the provider has yet to validate the contract. When the provider verifies the contract, if it receives 
CUSTOMER_ORDER
and that is unexpected, presumably the provider build should fail? If you are using 
can-i-deploy
, this check should not pass, because the provider is unable to satisfy the contract
His solution was to implement a matcher on the request field.
This is not a good solution, because it requires knowledge of the provider’s validation rules. In general, you should avoid matchers on the request unless you can’t make the unit test pass (which is usually a sign the code is not very modular)
é
In the consumer test, it won’t fail when the unit test happens if the response value is incorrect (it’s a mock of the provider at this stage, which has yet to be verified).
I reckon the use of matchers makes the test fail in a way they expect, the reasoning probably being "it fails for missing field, it should fail for invalid values". And instead of adding a unit test on the DTO serialization, they use a matcher on contract tests :/
m
mmm possibly
Did the other answer make sense to the team? Because it’s a unit test, they won’t see just yet if their mock is valid - only once the provider verification takes place do we know this, which is why 
can-i-deploy
exists.
f
Is this perhaps just a matter of using stringValue() instead of stringType()? Which one are you using?
👀 1
3 Views
Open in Slack
PreviousNext
Powered by