Integration testing with Postman and Newman

Automating unit tests as part of the CI/CD pipeline is now a given, but not so much for integration tests. This post will walk you through the whats, whys and hows of automating integration tests with Postman and Newman.

WHAT is an integration test ?

An integration test in this blog refers to a test which would need multiple APIs to run successfully in conjunction to get the right result. For instance, a test case to Book a reservation may involve the create reservation API, payment gateway API, confirmation notification API. WHY automate integration tests ? Automating integration tests has become the need of the hour as we move to agile development and delivery models. While unit tests are a good gatekeeper of the code health before it moves up the testing pyramid we found it was useful to integrate integration tests into the CI cycle too. HOW to automate integration tests ?

You can automate integration tests with Postman and Newman in 5 steps below.

1. Setup workspace: Download and Install go 1.17 : https://go.dev/doc/install Create your go workspace preferably in your user directory : ~/go/src Create project directory & Clone repo: > mkdir -p github.com/sshetty10 && cd ~/go/src/github.com/sshetty10 > git clone https://github.com/sshetty10/go-seed-db Build and run your server : cd $path_to _go-seed-db_clone go build ./go-seed-db
   

2. Install Postman and Newman: Install Postman : https://www.postman.com/downloads/ Install Neman: brew install node npm install –g newman​
   

3. Create your postman workflow and tests: Import sample collection into Postman from https://github.com/sshetty10/go-seed-db/blob/main/mycollection_with_tests.json Create a postman environment for your collection. {{tid}} or trainer ID will be saved as an envar in your collection's envar.
   

Fig. 1.1 GQLQA is the envar Postman workflow and tests have been added to the Add trainer Postman API. For Postman workflow : (Fig 1.1 line 13) postman.setNextRequest($name_of_the_next_api) creates a workflow. If setNextRequest is not mentioned then Postman uses the order of the APIs in your collection by default. For Test Assertions: (Fig 1.1 line 9,10) pm.test($name_of_test, test_func) is the a postman test block. You can create test assertions for your requests using pm.Expect.

You can also validate the response status codes using pm.response.to.have as in line 2. Once your collection is ready export the collection. mycollection_with_tests.json is a sample collection with the necessary test.

4. Run Newman from cli:

newman run mycollection_with_tests.json If you have any envars then export your postman environment as pm_envar.json and run: newman run mycollection_with_tests.json -e pm_envar.json​

Fig 1.2 If your assertions fail, it will also print the errors. (Fig 1.3)

Fig 1.3 5. Integrate Newman into your CI/CD pipeline:

We can integrate newman into our CI/CD pipeline. Currently, we have the integration tests set to run whenever there is a merge to the "develop" branch. This is a sample yaml script to include newman into your .gitlab-ci.yml file

integration_test:
	stage: test
	image: 	
		name: postman/newman:alpine
		entrypoint: [""]
		script:        
			- newman run mycollection_with_tests.json -e pm_envar.json​
		

Conclusion:

Postman and Newman together bring us one step closer to achieving a fully automated process from development to prod. While manual intervention is inevitable the more automated repetitive tests are the better it is not only for our code health and but also our mental health. Don't you agree ?