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:
Node (Version 12 or Higher)
JS Supporting IDE (WebStorm / VS Code)
Pact (contract testing framework for HTTP APIs and non-HTTP asynchronous messaging systems)
Prerequisite:
Following details are mandatory in order to have a successful implementation of CONSUMER end:
Consumer Name
Provider Name (based on the API version used by the CONSUMER)
API Details Like:
For API Request:
Base URI and Path
Supported HTTP Transactions
Request Headers
Query Parameters
Request Body (applicable only for POST request)
Supported Media Type (JSON / XML)
Valid Subscription Key (to be passed as header)
For API Response:
Response Code
Content Type
Expected Response Body
Required Dependencies:
Test:
Call To Mock Server:
Expected Response Body:
Test Execution:
“package.json” file consists of the command which help in executing the tests. It also consists of the commands that help the consumer to publish the contracts to Pactflow and to check the validation results locally using “can-i-deploy “.
We must always publish a unique version of consumer contract to Pactflow. Publish command will give an error if we try to publish the same contract twice.
How Does Consumer Contract Look Like?
FAQs
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).
