Streamlining API Testing with Postman – Part 3

by |

Photograph of letter-blocks spelling API for saving API queries
© StockFinland / istockphoto.com

In the last post, Part 2, we looked at creating and saving queries. This is useful for repeating actions that you’ve done before quickly. We showed how to create these queries, save them and create collections so that you can group them. Now, ideally you want to check the output of these was the same, or correct. For example when an API is changed to a new version you could run each one manually. Though a better approach would be to have Postman do this work for you for your API Testing.

Introducing Tests

Tests let you specify for each API query, an expected output. This might be for example that if you want to ensure that an API query contains a certain word, or that your API Token has the right permissions. We will run through an example of the later. Specifically: If I have a “Read Only” token, I shouldn’t be able to perform a “Write” action. The API should reject me. Conversely if I only have permissions to write data to the API, I shouldn’t be able to get a list of information out of it.

Lets have a look at one of the previously queries we saved:
Screenshot showing devices query
You can see in the section where we previously set the API Token (Next to Authorization, Headers, Body) there is a Tests section. Click on that and you can view and edit the tests for this particular query. Keep in mind these tests are per query. This means make sure you save your changes before editing another one, and also utilize some copy-paste if you want to easily move the same tests to another query.

Adding Tests

Writing your own tests will come with time and this requires a lot of experience (you can for example make sure that a JSON response matches a particular schema, regardless of the data inside it!). So for now we will just stick to the snippets that Postman comes with. For standard included snippets, they are very useful!

Scroll down the snippets list until you find an item called “Status code: Code is 200” and click it. It should add the snippet to the list of tests to the left, and you should have something that looks like this:

Screenshot showing the HTTP 200 Code Test Snippet

What you’ve just done is added a little script to your query, which will check something in the response from the API. It also lets you print a nicer message with the output, lets look at the elements of this snippet:

  • tests[“Status code is 200”]
    • Tells the script that you want to test, and that it should output the text “Status code is 200”
  • responseCode.code === 200;
    • Tells the script that you want to look  at the value of the response code. Then make sure it equals 200.

This is a very basic example! Check out the documentation for Postman on writing tests for more.

Test Output

What this basic example does though can be very handy. When a server responds with a ‘200’ it means it was a success. But it can respond with other things. If you recall in Part 1 of this series, we mentioned that a token has different permissions. A great use case for this example is that if I use a “Read” token, to request a list of devices from the API, it should work (and return ‘200’), but if I used a non-read token, it shouldn’t work, and would return ‘401’ (which means unauthorized). You can see below an example with both a read and write token:

Screenshot showing the Read succeeding and the write failing

 

If you look on the left above, we used a token with “Read” permissions to get a list of devices, and the test at the bottom passed, but on the right, we used a “Write” token, and the test failed. This is a very basic example, but it holds true for any test you write – Define the expected output, and if you get it, it was a success. But why is this important? Because when you are developing against an API, your application expects a specific response. If the response doesn’t match that, then your application might not work. So it’s good to have a series of tests for each output that you expect.

Test Runner for API Testing

So we’ve seen how we can determine the expected output of a query, but executing these one-by-one is annoying and involves a lot of clicking! Another cool feature of Postman is the Runner feature. This lets you take a collection of queries (which we covered in Part 2) and execute all of these.

When you have a collection of queries, you can simply click the “Runner” button in the top left. On the resulting screen, you can pick your collection (or collections) and the click “Start Test”. This will then execute each query in your collection, one-by-one and display the result. This becomes really important once you have collections with several queries in them.

Let’s take a look at an example, below I’ve got a collection with a few queries (which I’ve labelled so I can understand what the query was, very important!) Note that one is the same as the example above, “Read” gets a response of 200, In the other query, an expected 401 response, because I’d set my test script to expect that. I know that if I’m using a “Write” permission key for a “Read” operation, it should return a 401, so I wrote my test for that specifically:

Screenshot showing the results of the test run

So above you can see that I’ve chosen my “Devices Queries” collection, clicked “Start Test” and it’s executed the two queries that I had. One should check that a “Read” token works, and one checks that a “Write” token doesn’t. Both tests pass, so everything is good!

Though the examples above are very basic, you can see that API Testing with Postman is very simple to setup. You create your queries, set your expected output, and execute the tests.

Moving Forward

In the next post, we will look at how you can use different APIs that are available, and the various authentication options available for them. In the example of our server we are just using one authentication option, but there are several to choose from. There are also quite a few public APIs that are accessible, so we will go through accessing each of them for some more real-world examples and how you would authenticate to each one!

Leave a Reply

Your email address will not be published.