As microservices become the norm, ensuring our systems can communicate properly is now more important than ever. Having well written tests that we can easily modify and automate in our CI/CD pipeline will contribute greatly to this. To that end, let’s see how we can automate our API tests with Postman, a tool I’m sure many of us have come across at one point or another.

For this, we will be using Stephen Mangan’s post A Beginner’s Guide to Automated API Testing (Postman/Newman) as a jumping off point so will be assuming a lot of the knowledge from there. Primarily how we can export collections and environments as well as using Newman to run them from the command line. If you haven’t read it yet, now would be a good time to go and give it a look. Don’t worry, we’ll be here when you get back.

Using Stephen’s approach leaves us with files that aren’t easily readable and any changes to them involve importing them to postman if not already there, exporting once the changes are saved and replacing the older files in the repo with these completely new ones. This means that any change involves completely replacing our test file(s) so understanding and reviewing those changes on typical version control systems e.g. github becomes quite a challenge.

So, can we build on this to make the process easier for teams to develop and test? Let’s start by having a look at the Postman API.

Postman API

Running the Postman app without having an account allows us to make and manage collections locally. With an account, however, we can start to utilise the Postman API which backs up our workspaces, collections and environments in the cloud.

Thanks to this, whenever we save changes to our collection, these will sync automatically through the API and the rest of the team can view these by simply hitting the refresh button. One main disadvantage from this though is that we now have a copy of our tests stored with a third party so should be careful not to store any sensitive information in our collections or environments.

It’s worthwhile considering this aspect carefully as organisations may be averse to storing information externally with a third party. They may not be comfortable with any data being out of their direct control and ultimately having to trust that nothing is saved externally that could compromise their security.

Team Workspace

To work effectively with our team we should either set up a team workspace or a team account in Postman. The team workspace is free but is limited to only 25 active API requests, after which the oldest will be archived as historical requests, more info on Team Workspaces here.

Alternatively we could open a team account which has much higher limits on the number of requests and calls but does involve a monthly subscription so it is really down to what works best for your project and how much you’re willing to spend. Here though, we will just stick to the free team workspace.

You can’t convert the default workspace you start off with (‘My Workspace’) into a team workspace so we need to make a new workspace first and invite our team to it, defining the level of access to give each member as either admin or collaborator (Sharing workspaces, roles defined).

From here, everyone on our team can view and contribute to all collections and environments of our postman API tests without having to export and import various files.

#mmcalroy #testing #api