Creating a contract testing collection

The biggest downside to provider-driven contracts is the missing feedback loop. In this case, it is much harder for API providers to discover the interesting or unusual ways in which clients are using their APIs. This also means that since those configurations are less understood, they will be easier to break. Even if the provider can point to the contract and let the consumer know that they were using unsupported functionality, it is still never nice to break things that your customers depend on. Now that you have a good grasp of what contract testing is and how it works, let's look at how to set up contract tests in Postman.

Setting up contract tests in Postman

Creating contract tests is similar to creating any API test: you need to create a collection and then make requests in that collection with tests in them. But what kind of tests do you create when you perform contract testing? In Chapter 10, Testing an Existing API, I talked about smoke tests. These are a targeted set of tests that you can run quickly to get a good idea of how your API is doing. A contract collection is a similar idea, but with a bit more comprehensive coverage. The idea of contract tests is to describe all the different parts of the API that you need, but not to do things such as look at how to use them in a workflow or other aspects of testing. Contract tests are a good way to set the minimum bar for what needs to be working, but you will need to do additional testing beyond them for it to be effective. Of course, as with any other testing that's done in Postman, you will need to create a collection for your contract tests.

Creating a contract testing collection

Any collection can be used for contract testing, but if you have created an API specification, as I showed you in Chapter 11, Designing an API Specification, Postman provides some nice shortcuts for you. If you have not gone through the exercises in that chapter, you can import the API specification after getting it from the GitHub repository for this book (https://

github.com/PacktPublishing/API-Testing-and-Development-withPostman/tree/master/Chapter11). Once you have imported the specification, you can set up a contract testing collection by following these steps:

1. Go to the API by clicking on it in the APIs tab in the navigation pane. 2. Go to the Test tab. Then, in the Contract Tests section, click on the Add Contract

Test link.

3. Choose the Create new contract test option. 4. On the resulting dialog, name your contract test something like ToDo List

Contract Tests.

There are several options under Advanced settings. These settings are used by Postman when it's creating the collection for you. Since Postman will be programmatically generating a collection with requests in it for you, it needs to make some assumptions. These advanced options let you control how Postman makes those assumptions:

• Naming requests: By default, Postman names requests according to the path name, but if you choose the URL option, it will add the base URL to the request names as well. If you want to have your request name be something different, you can modify the OpenAPI schema. You can do that by going to the schema and setting a unique value called the operationId option under the path you are interested in. Once you've done that, you can choose the Fallback option here. • Set indent character: With this option, you can choose whether indented lines in the created collection will have Tab or Space indentation. • Collapse redundant folders: This option determines whether Postman should attempt to collapse redundant folders into one. Folders are redundant if they have only one child element and don't have any folder-level data to persist. • Optimize conversion: Leaving this option on will help with performance, so there is little or no reason to ever turn it off.

• Request parameter generation: When generating values for the parameters that the requests will use, Postman can either get those values from a schema or from defined examples. If you have examples defined, I would recommend using that option, since that will put actual values into the parameter fields instead of just giving you the data type. • Response parameter generation: This option works like the request parameter generation option. You can choose to either get the response parameters from a schema or from defined examples. I would recommend using examples when possible. • Folder organization: By default, Postman will create the folder structure in a collection by looking at the way that the paths in the specification have been defined. You can, however, have it generated in the folder structure using tags if you have defined them in the spec file. • Include auth info in example requests: If this option is on, the created requests will include authentication parameters in any created examples.