Hey! Iâm Rener Pires, and to submit this challenge I wanted to do something a bit different and share what I did for an INFOESTE lecture at my university in 2023 â itâs was a great experience and now I can finally update the material and project.
It happened when I was in the Postman Student Expert Program and hoping to apply for the Student Leader Program. At FIPP/UNOESTE in Presidente Prudente (SĂŁo Paulo, Brazil), we have INFOESTE â basically a circuit where students give workshops on different tech topics. My study group and I put together one called âDominando a Automação de Testes de API com Postmanâ (âMastering API Test Automation with Postmanâ) and we used a Blog API project as the example project. You can access the github repository here.
Iâm originally from Brazil, so the event name and collection names are in Portuguese â it helps reduce friction with students when theyâre learning and searching for resources.
Hereâs a photo from the lecture:
When we first built this, Postman CLI only ran on your machine â nothing for CI. So we did the obvious thing and used Newman to run our collection in GitHub Actions. It worked, we presented it, students liked it.
Then Postman CLI started working in CI. Weâd been meaning to update the material for a while, and this challenge was the push we needed. So now we have both workflows in the repo â Newman (the old way) and Postman CLI (the new one). That way students can see how things evolved.
The collection is called Infoeste Blog API. It hits our Blog API (Express + TypeORM + Swagger) and tests auth, posts CRUD, and user management. We use environment variables like {{baseUrl}} and {{bearerToken}}, plus the usual assertions in the test scripts.
To run the collection locally with Newman, you can use the following command:
newman run "https://api.getpostman.com/collections/2484339-33cb760a-1427-4a7d-aac6-369b4ba79fcc?apikey=${{ $POSTMAN_APIKEY }}" --environment "https://api.getpostman.com/environments/2484339-ad3b35d5-37c3-4881-ae79-91dfbd78d68a?apikey=${{ $POSTMAN_APIKEY }}"
To run the collection locally with Postman CLI, you can use the following command:
Locally we run it like this:
postman collection run "ci-local-newman.postman_collection.json" \
--env-var baseUrl=http://localhost:3000 \
-r cli,html
If youâre pulling from Postman Cloud instead:
postman login --with-api-key $POSTMAN_API_KEY
postman collection run 2484339-33cb760a-1427-4a7d-aac6-369b4ba79fcc \
-e 2484339-ad3b35d5-37c3-4881-ae79-91dfbd78d68a \
--env-var baseUrl=http://localhost:3000 \
-r cli,html
For CI we use GitHub Actions. The workflow spins up the API, waits for it to be ready (using wait-on), installs Postman CLI, and runs the collection. See here the ci-postman-cli.yml file.
The big win with CI?
Tests run on every push. No one has to remember to run them before merging. And also enables me to add a PR comment with the test results, so I can see if the tests are passing or failing (as well as git github pages to show the report). Same environment every time, no âworks on my machineâ â and in the workshop we can show students the whole path from manual Postman tests to automated runs in CI.
Another big win with Postman CLI in CI? When you authenticate and run a collection by Collection ID, every pipeline execution is automatically linked back to the Collection Runs section in the Postman UI. This creates a central, visual history of CI runs directly in Postman â not just logs in GitHub Actions â and helps teams understand what logging in with the CLI actually enables.
You can see these runs here: View Collection Runs.
Beyond full collections, the Postman CLI also supports more targeted executions, such as running a single request for smoke checks, or triggering an existing monitor directly from CI.
Suggestions:
Built-in wait capability
One thing Iâd love: a built-in way to wait for a service before running. Right now we use wait-on because the API needs a few seconds to start. Something like --wait-for-url http://localhost:3000 would be nice and would cut out that extra dependency.
Official GitHub Actions templates.
Postman could provide official GitHub Actions workflows for running collections in PRs (with comments) and deploying HTML reports to GitHub Pages. These are common CI patterns and would greatly simplify setup and adoption.
Native support for running tests by tags or scenarios.
In CI, itâs common to run only a subset of tests depending on the context (smoke tests, regression, auth-only, etc.). A built-in tagging system for requests, folders, or tests â and the ability to run them selectively â would make this much easier.
For example:
postman collection run <collection> --tags smoke,auth
FYI/FFR: Repo is infoeste-blog-api, and hereâs the event page for INFOESTE 2023 â Dominando a Automação de Testes de API com Postman.
What Collection I Ran
Postman CLI Command Used
How I Ran It in CI (GitHub Actions)
One Advantage of Running in CI
Suggestion for Postman CLI
Submissions are closed
Challenge winner