API testing with Postman and Newman
Here at devgurus we value Quality and in our constant search to improve it every day we find ourselves in the need to test our APIs, and if you still aren’t testing yours you should.
Why? Every day we are more dependent on APIs, and testing them is the best way to ensure they’re working 100% as expected all the time. If they’re not working as expected, having automatic tests for your APIs in your development cycle is the fastest way to notice those malfunctions before they can affect your software.
Just as quality code, quality APIs should be documented, integrating the testing from the beginning of the development it’s a great way to ease the burden of documenting them. Testing does not only makes them more readable but one of the programs we used here can also automatically generate very complete documentation for each request.
Our code coverage won’t be complete without API testing, when done right, it can improve not only the quality of our software (more coverage = fewer bugs) but also our confidence in the code and its maintainability.
What to test?
Once we decide that we are going to test our APIs, we should start by defining what sort of requests can be made and what data is necessary for each one, this should be in the documentation.
Some of the first questions we should try to answer beforehand are:
- Which endpoints are available?
- What sort of authorization those endpoints use?
- Wich fields of a request are required, and which are not?
- What response code should I expect?
After we’ve answered those questions (via documentation, asking developers, reading code, etc.) we can start building a “collection” of requests looking to cover each request and each possible response (not only the successful ones); then we can start by defining two big groups of request:
“A happy path” where the world is perfect and all worked just fine since day 1 (never happened), testing things like:
- A 200 Response
- If the response includes a body, there should be an assertion for the structure and the content
“How did I end up here” or what happens in the real world:
- Sending a request with the wrong HTTP verb.
- Sending a request to the wrong endpoint.
- Sending a request with the wrong headers.
- Sending a request with missing headers.
- Sending a request without the proper authorization.
- Requesting data for a record that does not exist.
- Sending a request with a body that has missing required fields.
- Sending a request with a body that has invalid field values.
How to test?
With a defined plan for testing we can start looking for tools to carry it out, we at devgurus decided to use Postman for the management of API requests and Newman for the integration in the CI.
Postman is an IDE for APIs where you can create requests collections, tests (powered by Chai.js), manage variables (globals, by environments, locals) and generate documentation (among other things).
We should start making a collection with every possible request, and their possible responses, and adding some basic testing.
Testing in Postman is very simple and powerful, we can add scripts at the collection level, folder or request and those can run before the request is sent or after the response ir received. Postman also includes a good number of snippets so you don’t have to memorize them, those include things like assertions in the body, in the response or even assertion over the entire structure of the response.
As you can see in the first image we are using variables for some parts of the URL, in Postman we can have Local, Environments and Global variables, in this case we are using variables to cycle through each environment.
One of the great tools that Postman provides us is the automatic documentation feature where we can make a sort of documentation for the API, with the endpoints, descriptions, their params, response examples, etc…
Once every request has its documentation and tests we should look for the way to integrate it into our CI.
Newman is the tool we choose to integrate this testing to our development cycle, it’s a console runner for postman collections, that also can generate a report in html or json (to name a few examples), after installing it we only need to add the location of the collection file exported from Postman.
Integrating with Bitbucket Pipelines was very simple and straightforward, we added the collection file and their variables collection to the repository, and just a few lines to our bitbucket-pipelines file, with the installation of newman, the reporter and the run command.
Final notes
With this article we’re not looking to turn you in an expert, is just a quick guide showing you how easy is to start with API testing, making emphasis in the great benefits you can obtain with so little effort. Now is your turn, give API testing a try, and leave us a comment with your history, questions or anything related.
—
In devgurus, we always invest in technology and offer the most innovating technologies to our clients. If you are interested in knowing more success stories don’t hesitate to contact us: support@devgurus.io,
