Prerequisites

What You'll Learn

What You'll Build
  1. Fork the collection - Click the Run in Postman button to fork the collection to your own workspace.

Run in Postman

  1. Select the first folder - Begin with the first folder labeled "1. The Power of Libraries", and expand the documentation from the context bar on the right. Instructions for each lesson will be in the documentation for each folder.

Follow along with the webinar

View the slides here, and watch the webinar (originally aired September 22, 2021).

Additional resources

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.

Additional Resources

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:

Iterating over a data file

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 films.csv:

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.

Additional Resources

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:

  1. Create a new collection in your workspace, called "Monitoring Demo".
  2. Locate the Simple Linear Sequence folder in the "Using the Runner" folder, and select "Duplicate" from the context menu.
  3. Select the duplicated folder (it will be called "Simple Linear Sequence Copy") and drag it into your "Monitoring Demo" 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.

Additional Resources

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:

  1. Export the collection that you wish to run. We'll use the "Monitoring Test" collection from the previous exercise. Open the context menu for the collection, and select Export.
  2. Save in the recommended format, and give it the filename mycollection.json.
  3. To run from the command line, browse to the folder where you saved your JSON file, and type the following: newman run mycollection.json
  4. The results of the tests will be output into the console.

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.

Additional Resources

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.

Run in Postman

What we've covered

If you want to learn more about testing and automation in Postman, check out the following resources. Keep on learning!

Additional Resources