Overview
Postman, more than and utility, is a collaboration platform for developing APIs.
Normally, it is used as a way to quickly interact with existing APIs without having to code HTTP requests by hand.
It provides support for HTTP based APIs, including REST and GraphQL.
Postman also provides the ability to write tests and use Chai assertions, as seen on these Postman test examples.
With Postman, comes also a built-in (test) collection runner; it is also possible to execute tests from the outside, using a CLI tool named "newman".
Concepts
- request: an API request (e.g. HTTP POST on some URL, with some values)
- collection: a way of grouping multiple requests
- folders within the collection: a way to better organize requests within the collection
- variables: can be defined at multiple levels (e.g. global, collection, environment, local, ...)
Implementing tests
Tests can be implemented using Javascript and making use of Postman APIs/objects supported by Chai assertions.
One or more tests can be defined at the request level, or even at the whole collection level.
One thing that may be useful, is pre-r
Requirements
- Postman
- Jenkins plugin (optional)
Example
Postman Echo API
In this example, we're going to use Postman' sample Echo API as a way to showcase some tests and their integration with Xray.
The Postman Echo API provides a set of endpoints that we'll exercise.
We start by cloning an existing Postman collection from a template and importing it to Postman.
The collection contains a request per each endpoint, where each request has one or more tests.
In the previous example, we can see two tests: one for validating a successful HTTP request based on the status code and another that checks the response's JSON content.
The collection (or a subset of its tests) can be run using the Collection Runner.
Running the tests can be done from the command line or from within Jenkins (or any other CI/CD tool); this will produce a XML based report (e.g. output.xml).
Importing results is as easy as submitting them to the REST API with a POST request (e.g. curl), or by using one of the CI plugins available for free (e.g. Xray Jenkins plugin).
An unstructured (i.e. "Generic") Test issue will be auto-provisioned the first time you import the results, based on the name of the test case and of the corresponding test suites.
If you maintain the test case name and the respective test suites, the Test will be reused on subsequent result imports. You may always enforce the results to be reported against an existing Test, if you wish so: just specify its issue key as a tag.
Tags can also be used to cover an existing requirement/user story (e.g. “ROB-11”): when a requirement issue key is given, a link between the test and the requirement is created during the results import process.
Otherwise, tags are mapped as labels on the corresponding Test issue.
A Test Execution will be created containing results for all test cases executed. In this case, you can see that it is also linked back to an existing Test Plan where you can track the consolidated results from multiple "iterations" (i.e. Test Executions).
Within the execution screen details, accessible from each row, you can look at the Test Run details which include the overall result and also specifics about each keyword, including duration and status.
