-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option to check for no undeclared fields #84
Comments
You might be interested in: https://docs.pact.io/getting_started/matching/gotchas/#pact-follows-postels-law Pact is primarily for contract testing, as in "can this consumer communicate with this provider" - perhaps I'm misunderstanding your request, but it sounds like you're trying to do something outside this remit. You might want some kind of spec-based validation on top of Pact, perhaps. |
Hi @TimothyJones , yes I've read it, my point it is configuration options can be added to support different kinds of behaviour. It's not that this law is built into stone, right? :D And anyway it's broken for headers already, so I want to know team's opinion on it. |
I agree with Tim that perhaps you need another tool on top of Pact if you want to restrict the fields in the response. What would you do if you had two consumers, and only one consumer used a particular field? You'd have to make the other consumer add that field to their contract, and then you'd be back in the SOAP world, where every consumer has to update their interface document when one consumer needs to make a change. That's something that CDC's were specifically designed to avoid. |
Hello, as I understand currently Pact only checks for fields declared in the contract and allows any number of other fields. I would like to have an option to do a 'strict' check so that no undeclared fields are allowed, in my case for a privacy & security reasons.
Do you think it makes sense to have this feature? Maybe you already discussed something like this?
Thanks!
The text was updated successfully, but these errors were encountered: