API development is everywhere these days.  With Microservice architectures taking off, and JavaScript frameworks needing a way to talk to their servers, writing the server-side code to be exposed through an API is ubiquitous.  So when it comes to testing all these APIs to validate that they are running, you need a tool that will easily give you a way to test an API without having to code specific clients to call each API.  Postman and it’s command-line-interface partner Newman are just such a tool, and have become a popular tool to have around for just such tasks.

Now, writing scripts in Postman to test out your API is all well and good, and can give you a great way to validate that the API behavior you expect is what you are getting, and also can serve as a way to document what your APIs are doing.. BUT now, how do I get to run those scripts as part of my release pipeline so that I can take advantage of that automation goodness? And while the Postman enterprise accounts will store your scripts, and help you organize them into workspaces, it doesn’t do a wonderful job of keeping history for you.

For Azure DevOps I found a nice little task out in the marketplace to run those Postman scripts through Newman in your build or release pipeline

Newman CLI Task for Azure DevOps

This task is great, and runs our scripts just as needed.  However for our needs, this gave us a great way to run scripts that we have downloaded from Postman, but while we utilize the Postman Enterprise account, we didn’t have a way to run scripts from the Postman Enterprise account directly, requiring us to have a method to pull the scripts down from our Postman account.

So, I’ve created a new task now in the marketplace

Get Postman Scripts

This task will utilize the Postman API to retrieve the scripts your account has access to.  This solves two troubles for us.  We can now pull down all the scripts that the QA Team are building in the Postman Enterprise account workspaces so that we have them locally.  This means we can easily utilize the Newman CLI task to run our scripts while still giving the QA team the ability to use their Postman Enterprise account.  AND it gives us the added benefit of giving us a way to store those scripts in Git so that we have a good history of the scripts.  That means if a script worked against a version of an API, and later scripts seem to be incompatible with an API, we can go back! All the benefits of source-control history for our Postman scripts can now be leveraged.

My Get Postman Scripts task will require you to go in to Postman to generate a Postman API credential key token.  This will require you to log in to your team’s postman workspaces on the Postman website (I haven’t found a way to do this directly through the Postman client).  Then choose the Integrations Tab, and then Browse Integrations, and finally choose the Postman API, from there you can choose to generate an API Key.  Keep that key safe and treat it like a password, it’s your access to the Postman API for your credentials.  Once you have that key you can enter it to the Get Postman Scripts task in your build pipeline and it should start pulling down scripts for you!

How I’m using this today on a team project:

I have created a git Repo to hold our Postman scripts, and I have a Pipeline Build created and scheduled to run weekly for now; we will move it to run more frequently as use of Postman becomes more wide spread.  That Build utilizes the Get Postman Scripts task to download the team’s tests from Postman.  The build also issues Git commands to keep our Git Repo up to date with the latest scripts.   In our release pipeline for our APIs, we utilize the Newman CLI task to execute the appropriate Postman tests against the API we released!  There you have it, automated API testing through Postman and Newman.