AiTOnline is a fortnightly Twitch livestream ‘AiT Online’ in which Mark and Richard explore a different testing tool or automation tool. Each stream is followed up by a debrief to share highlights, features and thoughts on what was covered. If you’ve missed any of the streams, you can view them on the AiTOnline YouTube channel.
On the 11th July, we got together for our third AiTOnline and spent some time looking at the popular API testing tool, https://www.getpostman.com/. As always we used our automation playground, Restful Booker Platform, to demonstrate how Postman enables us to test and explore web APIs.
You can watch the full video or we’ve broken it down into the main sections below.
Introducing Postman - 3:40 - 9:21
As Richard mentioned during our session, Postman is a massively popular tool when it comes to API testing with both Testers and Developers adopting the toolset for various activites. We’re no strangers to Postman ourselves with both of us using it heavily in projects both personal and professional for many years so our focus for this session was to share what we know about Postman with each other and our viewers.
So to start with we highighted where to get Postman from and to watch out for the deprecated Chrome app version of Postman that is no longer supported. We then took a step back to discuss why testing APIs is important as well as the value in testing APIs, such as:
- The ability to create more targeted tests for an API
- A quick way to create data in an application
- Changes in technology and development approaches such as Microservices and IoT mean API testing is a necessity
Finally, we took a quick look at our automation playground to determine what APIs to begin playing with.
Creating requests - 9:21 - 18:24
Once we knew what we wanted to work with, our next step was to start learning about the API endpoints we ultimately were going to test with Postman. So our next step was to use browser developer tools, a tool we explored in a previous AiTOnline to discover the API calls that are triggered in our application.
With our API calls identified we began to explore the features of Postman by starting a new request and saving it to a feature called a Collection which enables us to store multiple requests that can later be shared or run in an automated fashion. We also looked at some of the Postman Pro features around Collections that enable a team to sync collections and their requests across team member’s installations of Postman.
We also looked at how rather than manually creating a request in Postman we can port them across to Postman using a handy copy and paste trick to copy HTTP requests from browser devtools to Postman.
Sending GET requests - 18:24 - 22:03
With our API request now populated in Postman we sent our first request to the automation playground API and began to explore the details of the HTTP response such as the body, status codes and timings. This lead to a discussion about API documentation and specifically tooling such as Swagger which we use heavily in our application.
Creating data with POST and beyond - 22:03 - 31:11
Once we had created a basic GET request, we moved onto exploring how to POST data to an API endpoint starting with the login endpoint of Restful Booker Platform. Once again, we used browser dev tools to discover the API endpoint for login, the data that is sent and the headers it requires before copying it across using the copy and import trick from before.
The import of the request revealed a new feature, the body feature of an HTTP request that enables us to add in data that we want to send in our POST request. In this instance we had copied JSON across from the browser which could be formatted in a readable fashion (and can be edited). With everything in place we sent off our POST request and after a few slip ups we received an HTTP response to review.
We then discussed the different methods that Postman supports whilst discussing the wider differences between PUT and POST and the ability to explore PATCH endpoints with restful-booker.herokuapp.com.
Environmental variables - 31:11 - 39:07
Richard then set me a challenge to help demonstrate the use of environmental variables in Postman by using the feature to store login details and host details for future use. We explored how to create a environment, add a range of variables within the environment and then use them within the stored requests in our collection. This feature is extremely valuable for quick switching your requests between environments or data sets. We also ran into some issues with current values and initial values which threw me off a bit
One final thing we discussed was the global variables and how they differ from environmental variables. They are used in the same way as environmnental variables but regardless of environment, the global variable will always be the same.
Automating with Postman - 31:11 - 52:05
Working with the Postman runner - 52:05 - 57:31
With our API requests saved in a collection and assertions and other behaviour added into the Tests tab, we were ready to look at how we can trigger an automated test run within Postman. We looked at how to start up the runner, discovered some new features around editing the run order of requests in test run and then discussed how to configure a test run with a specific environment variable set before running the Collection.
Once our collection ran, we explored the reporting features to learn how to deep dive into how the requests behaved in the test run and what responses were returned.
I also demonstrated some unconventional uses for the runner in Postman. It’s commonly used to trigger automated API test runs but I showed how it can be used to rapdily create test data when running other testing activities.
Running Postman headless with Newman - 57:31 - 1:10:27
The final thing we explored was an addition to the Postman ecosystem, Newman. Newman allows us to run Postman collections headlessly meaning we don’t need to have Postman installed and running to execute automated API tests. This proves particulary handy if we want to run these API tests on a continuous integration system or some other build pipeline.
If you have NodeJS installed you can then install Newman and once installed Newman takes exported collections from Postman and executes them for you and then outputs a report after the run is complete. We also learnt how Newman can take exported environment configurations to make it nice and easy to switch environments headlessly as well. We also spent a little bit of time exploring how Newman can take plugins by installing a plugin created by Danny Dainton called Newman-reporter-htmlextra which presented reports from Newman in a very shiny way.
One of Postman’s main selling points is it’s shallow learning curve, you can start capturing and sending API requests very quickly and from there it doesn’t take much more to drop the requests into a Collection and then run it as part of an automated test run. The key to mastering Postman however is understanding and exploring the wider features it offers around variables, the test runner (and Newman) and using Pre-request script and Tests tab beyond just simple assertions. Something I hope we demonstrated in the livestream.
Looking back on our session it felt much like our first session with DevTools we only just scratched the surface of Postman. Beneath its well formed UI and smooth user experience Postman offers a wealth of features and tools beyond automatinng APIs that we simply ran out of time to look at. Perhaps we will return to Postman in a future session to learn more about it’s monitoring, API design and mocking features as well as some of the more advanced behaviour you can trigger in the automated test runs.