Should we include value matching as part of contract validation?
we are using pact for contract testing. For an api that is being used in two different context, would respond with different values in the response (though the fields and format of the responses are same.) Should we cover this as two different interaction ? if yes, is it not like testing the business functionality?
This will have implication in the following case too... we are using contract test for backward compatibility validation of our mobile app. If there is a change in api, where only the value of the response have changed. And if the change work for current version of the consumer, but not with the older version. This is will break the backward compatibility of the provider with the older version of mobile app. How will we be able to catch this, if we only consider the structure of the response as part of the contract tests?
It's a good question and there is no straightforward answer for it in all cases.
The first thing I'd say on this, is that structure alone is not a contract test - it's more a schema test - and schemas are not contracts. Contract tests do care about values in many cases.
Start by working with the following operative:
The rule of thumb for working out what to test or not test is - if I don't include this scenario, what bug in the consumer or what misunderstanding about how the provider responds might be missed. If the answer is none, don't include it.
In your case the value of role has a specific enum-like meaning. I assume that the consumer code looks for this value, and might conditionally do something different based on its value. For example, if it were a UI it might display different options alongside the page, or fetch other relevant data.
If that's the case, then you would potentially want to include it as a contract test. If the UI doesn't care about the value of the field other than to display it, then it wouldn't be worth including in a contract test
if yes, is it not like testing the business functionality?
Well, not exactly. Contract tests are not functional tests, but like many types of testing there is overlap. Your aim here is to ensure the various important conversations that are are expected to occur between a consumer and a provider are covered. Functional testing is a separate activity that can primarily be distinguished by its concern for side effects.