Testing Routes With Postman

When building an app one of the many things that need to be set up and tested are the routes. In the Rails world, these routes determine which controller action will be used when a user makes a POST or GET request to a certain web address. If these routes are incorrect then your app may do unpredictable things or may not work at all.

To make sure the routes are set up correctly, you should test them. If you have a small app with just a few routes, this may be as easy as firing up the server and browsing to a few web pages. If pages render correctly or if items in the database are updated then it looks like things are working as expected. But what happens when you have more than a few controllers each with their own set of RESTful routes? What if you have a dozen controllers? A hundred? Is someone going to have to browse to each of those routes and make sure they work? Is that someone you? What happens when you make a change to the app? You have to retest all of those routes again.

There has to be a better way! Well, there is. Probably many ways, but this post focuses on Postman (https://www.getpostman.com/). It is available as a stand-alone or Chrome app and is pretty easy to set up and use. The interface gives you a request editor where you can provide the different parts of a request like the URL, the HTTP verb, and any params you want to pass along. You then have an option to send the request or save it for later (very helpful, which you will see in a bit).

Postman GET request to google.com

After sending the request, you get a lot of information back, including the status code, headers, cookies, how long the request took, the size of the files returned, as well as the raw HTML, JSON, XML, etc.

Information returned from the GET request to google.com

For a POST request I can pass in different parameters and see the result. In this case, there is an issue with this request so I see a 500 status code.

Sending params through a POST request.

These even trigger debugging tools like ‘pry’ or ‘byebug’.

A binding.pry debug tool triggered by the POST request from Postman.

Another option is to run a ‘test’. This gets a little more granular than just running a typical GET or POST request. You can set a test for what is contained in the response body, or a JSON value check, or several other options. You can add several tests to one request and chain them together.

Here I added a ‘Successful Post request’ test to the above POST and can see the result of ‘Fail’.

These examples are great if you want to test one page at a time. What about the earlier example of when you have more than one or two routes to test? Or what if you have to pass along several params to a POST. Postman allows you to set up the route test once, save it, and then run it again later with the different options saved. You can also group these saved routes into a collection.

A collection of different requests for the same app. All of these can be tested at once.

This eases the pain a bit if you have several sites to test. But if you really want to have a one-click-and-done solution, you need to go to Postman’s ‘Runner’ option.

The Runner option in Postman

The Runner will list your current collections and allow you to run all them at once including any individual tests you may have added. You will also have access to statistics that will list the results of previous tests.

Result from a Postman Runner test of a collection of routes.

As you can see, I was able to run all of the tests in my ‘Yelp API’ collection with the click of one button. This lets me quickly see if all of routes are up and running and if not why not. If I make a change to this app, I have a way to quickly test the routes again without too much trouble.

This is just scratching the surface of all the tools that Postman gives you, but I hope you can see how its automated tests can help you find and diagnose issues. Now I’m off to debug this app.