View the slides here, and watch the webinar (originally aired September 22, 2021).
Feeling stuck or want to dig deeper into specific topics? We've got you covered:
When we talk about ‘Tests' in Postman, we are typically referring to scripted checks which are written in the Tests tab of a request (or at folder/collection level, if you want the tests to run against every request within).
These are often written as assertions, in the style "expect SomeVariable to equal X". The most common library for this is the Chai Assertion Library, which (in conjunction with Postman's own sandbox API) allow you to perform complex checks against both request and response data, including metadata such as headers and response time.
But there are many additional libraries available which can massively simplify your day-to-day operations, and reduce the amount of custom code that you need to write:
To see some examples of what's possible in Postman, visit each of this folder's requests in turn, and look at the Tests tab of each request. You can also send each request, and look at the Test Results section of the response pane.
We've only scratched the surface of the many different libraries that are available through Postman. Here are a few more that you might like to read about:
Often when testing a scenario, you'll want to run multiple requests consecutively. For example, you might send a
POST request to submit some data, and then you want to use a
GET request to check that the data can be retrieved. This is where Postman's Runner comes in handy, allowing you to chain together requests in an automated fashion.
There are many ways to launch the Runner, depending upon how you want to interact with it. One way is to click the ‘Runner' button in the bottom-right of the UI, and then drag-and-drop the collection or folder that you wish to execute.
In this folder, we are demonstrating three different methods of running a folder of requests:
setNextRequestcommand to repeatedly run the second request multiple times until all scenarios have been run.
For this example, we will utilize a CSV data file to drive our tests. Download the file by clicking here.
If you are unable to access this file, you can recreate it for yourself by copying the below text, and saving it into a file such as
id,title,year,imdbUrl 918,Central Intelligence,2016,https://www.imdb.com/title/tt1489889/ 600,Doom,2005,https://www.imdb.com/title/tt0419706/ 441,Get Smart,2008,https://www.imdb.com/title/tt0425061/ 306,Hercules,2014,https://www.imdb.com/title/tt1267297/ 1794,Pain & Gain,2013,https://www.imdb.com/title/tt1980209/ 286,The Other Guys,2010,https://www.imdb.com/title/tt1386588/ 720,The Scorpion King,2002,https://www.imdb.com/title/tt0277296/ 814,Walking Tall,2004,https://www.imdb.com/title/tt0351977/
Once you have saved or created the file, click the "Run" button in this folder, and in the Runner options, browse to the file via the "Select File" dialog.
Once you have successfully selected the file, you can click "Preview" to confirm how Postman is intending to interpret your data.
More detailed documentation about the functionality of the Runner can be found in the following documentation:
Having tests which are executed whenever you run requests is great, but these will only alert you to test failures when you choose to run them. One way to get faster notification of changes/failures is to take advantage of Postman's Monitors. These are run automatically at a scheduled interval, and can notify you via email notifications, or other plugins such as Slack or PagerDuty, if new failures are detected.
Note that while monitors can be run on both free and paid plans, there are monthly usage limits for all tiers; more information can be found in the documentation linked above.
Because a monitor runs against all of the requests within a collection, for this exercise we'll duplicate an existing folder into a new collection:
Now you can go to the Monitors tab in the left sidebar, and set up a monitor for your "Monitoring Demo" collection.
Once you're finished with this exercise, you may wish to pause the monitor so that it is not continuing to use your monthly allowance. You can perform an ad-hoc execution of a monitor at any time.
In this exercise, we'll build upon the work from the "Automating with Monitors" section, so ensure that you've completed that exercise beforehand.
Newman is the highly configurable command-line runner which allows you to extend the power of Postman's testing interface, allowing you to integrate execution into your continuous integration servers and build systems.
Once you've set up these prerequisites, it's incredibly simple to perform your first command-line run:
newman run mycollection.json
There are many useful advanced features of Newman which you might want to utilize, depending upon your CI setup:
More details on these configuration options can be found within the documentation below.
Sometimes when we're regression testing an endpoint's response, we don't want to write dozens of assertions to validate the values that are returned. Instead, we'd prefer to check that the response is the same as the last time that we asked (or at least that the structure is syntactically identical).
One way to achieve this is to take advantage of the Mock Servers feature in Postman. Typically, the purpose of a mock server during API development is to simulate the request flow before the production API has been constructed, by asking Postman's mock server to return a specific example response in a given scenario. But as testers, we can save real responses as examples, and write tests to compare future responses to these benchmarked examples.
To see this in action, you can fork the Snapshot testing using Postman collection into your own workspace, using the button below, and follow the documentation within.
If you want to learn more about testing and automation in Postman, check out the following resources. Keep on learning!