Mr. Postman for Integration Testing

Published in

Backstage

4 min readAug 22, 2019

Integration Testing

Yes we do unit testing, we do integration testing but everytime we write a new api do we test the schema and positive + negative test cases religiously, most of the time the answer will be NO. Integration Testing is a level of software testing where individual units are combined and tested as a group.

Why Postman?

We had created something called Lakshman Rekha (centralised integration testing platform) in the past and then every microservice needs to integrate with it to TDD/BDD the test cases. 2 problems — Maintenance and Adoptability of the Lakshman Rekha itself. Thus we chose Postman because it is handy, developer use them on day to day basis and it provides separate workspace for different teams + well groomed documentation.

What is Postman WorkSpace?

We performed some R&D and found out Postman can be used for Integration Testing with a simple learning curve of chai.js and one time learning of Jenkins integration. Thus we bought the Postman Pro license and created different workspace (a workspace isolates your development, testing and production deployment by sharing collection and allowing you to manage roles of different developers)

My WorkSpace — Directly links with your Postman Client (local)
Team WorkSpace — This is the one you create for your own team (prod)

Most of the team will have either Viewer or Editor roles in these workspace.

How does the Tests work?

If we all understand Postman Collection then the tests/assertions can be written under 3 levels — Collection, Folder and Request

And this is how you structure and run the whole collection i.e.

Create Collection for your microservice > Create Folder for each module > Add Requests with Positive/Negative Tests >>> Run

We have following 5 thumb rules for the process point of view

1) Workspace should have collection same as Github repo name

2) Each collection should have module based Success/Failed cases

3) Fork and Merge request — Postman Collection <collection_name> merge request email

4) Always work on MyWorkSpace and raise a request to Module Owner to merge the changes to Team WorkSpace

5) Integrate your repo’s collection with Jenkins job for deployment

Who is this “newman”?

Once the collection is ready with requests and tests you would like to run them and there are various ways you can run them

different ways to execute/run postman collection

Everybody wouldhave tried In App (Postman Client) runner but Commandline and CI Builds run via newman which is a command line collection runner for Postman. Simple to install npm install newman and check newman — version (we use 4.5.1), Copy the shared collection url and

newman run <shared_collection_url>
(This is the most easy way to run for your Postman collection)

What about Collection URL security?

Yes, the shared collection URL is a security threat and sharing it over network via Jenkins command was also a concern so we discussed with Postman team and figured out we can use Postman API as a safe option which converts the command line script from newman run <public_shared_collection_url> to

newman run https://api.getpostman.com/collections/{{collection_uid}}?apikey={{postman-api-key-here}}or if you are interested to pass your specific environment global variables then the newman run command changes tonewman run https://api.getpostman.com/collections/{{collection_uid}}?apikey={{postman-api-key-here}} --environment https://api.getpostman.com/environments/{{environment_uid}}?apikey={{postman-api-key-here}}