Hello, general question about consumer driven contract test when updating or adding new resources. In our team we are in a situation where the Consumer calls an HTTP endpoint to update a resource with a bunch of fields such as { name: "Vittorio", surname: "Surname", extraField: "Hello"} The Provider only cares about name and surname. The provider API for the Patch endpoint is not strict. If you send extra fields it will just ignore them. But you can see how the consumer could change the field name by mistake and the provider verification will not fail. We are currently not returning the fields that were updated or the new entire resource. What is the best way to ensure that the resource is updated? We were planning to make the interface strict so the Provider will fail if you are sending unknown fields but I was wondering if you had any other suggestions based on your experience with consumer driven tests.

Yeah, that’s about the only advice I have here. My assumption is that at some point, you’ll have a corresponding call to GET (or similar) and at that point your data model will be incorrect (i.e. you’d expect

extraField

in the response, but it wouldn’t exist). It’s a tricky scenario to test, but I would still prefer to follow Postel’s law here, and not have the API complain if it receives a field it doesn’t recognise

I do agree, i would prefer returning the updated resource. Unfortunately we are not following any standards and the update model is different from the model retrieved. This is probably the issue rather than the testing itself. This inconsistency creates more mental load and difficult to track what changes what etc! Thanks