Overview
This Tutorial documents and illustrates the solution for the Consumer End Implementation that was performed against the ‘GetProducts’ API in CDS. This can serve as a reference for how CONSUMER tests and workflows can be done.
Required Tools:
JDK 10+
Apache Maven 3.6+
IntelliJ/Eclipse IDE
Prerequisite:
The following details are to be collected to implement the CONSUMER side:
I. Consumer Name
II. Provider Name (based on the API version used by the CONSUMER)
III. API Details Like:
a. Base URI and Path
b. Query Parameters
c. Headers
d. Supported HTTP Request Method
e. Body for POST Request
f. Supported Media Type (JSON / XML)
Required Dependencies:
Coding Part:
Interaction With Mock Server:
Expected Response Body:
How Does Consumer Contract Look Like?
FAQs
Below are the concerns/questions that people happen to come across while implementing consumer driven contract testing.
1. How to resolve Consumer End Error “Request failed with status code 500“?
- There must be a mismatch between path, headers or query parameters in your interaction written inside the test and axios request constructed in your code. Make sure the path, headers and query parameters are identical inside both axios request and interaction.
2. Why don’t we use JSON Schema instead of creating an expected body at Consumer end:
- Whether you define a schema or not, you will still need a concrete example of the response to return from the mock server, and a concrete example of the request to replay against the provider. If you just used a schema, then the code would have to generate an example, and generated schemas are not very helpful when used in tests, nor do they give any readable, meaningful documentation.
3. Why is there no support for specifying optional attributes:
- If Pact supports making an assertion that element $.body.name may be present in a response, then you write consumer code that can handle an optional $.body.name, but in fact, the provider gives $.body.firstname, no test will ever fail to tell you that you've made an incorrect assumption. Remember that a provider may return extra data without failing the contract, but it must provide at minimum the data you expect. The same goes for specifying an array with length 0 or more. If all your provider verification data returned 0 length arrays, all your verification tests would pass without you ever having validated the contents of the array. This is why you can only specify an array with minimum length 1 OR a zero length array.
- Remember that unlike a schema, which describes all possible states of a document, Pact is "contract by examples". If you need to assert that multiple variations are possible, then you need to provide an example for each of those variations. Consider if it's really important to you before you do add a Pact test for each and every variation however. Remember that each interaction comes with a "cost" of maintenance and execution time, and you need to consider if it is worth the cost in your particular situation. You may be better off handling the common scenarios in the pact, and then writing your consumer to code to gracefully handle unexpected variations (eg. by ignoring that data and raising an alert).
4. Pact Server Error:
- A couple of times it has been observed that the Pact Server does not start at all and the your are unable to generate the Consumer contracts. It gives a weird error code and fails the execution, errors like below (generally observed in Pact JS). Pact Exited With Error Code 1 OR Error: the process 3748 not found (the process ID could vary) In order to resolve this error, please refer to this link Pact exited with code 1
