The Postman test Sandbox contains several useful libraries, functions and objects for testing. A list of them can be found on the Postman Sandbox reference page.
Contract tests allow you to verify that API request and response schemas have not changed. This is especially useful when working on a mobile application with a large team with separate mobile and API developers.
First you must generate a JSON schema for the response bodies. If you don’t want to do this by hand, you can use an online generator, like the one at jsonschema.net. For this demonstration, I’ll be running tests that verify that Alpha Vantage’s Stock Quote API contract has not changed.
The function will return an object with a valid property that will be true if the object matches the schema.
In addition to the schema, it is useful to check that response codes and content types are all as expected. Since Postman does not return much detail about failures, it is best to only put one assertion per test, to pinpoint exactly where the error has occurred.
You can test this sample in Postman with the collection.
Postman tests can also be used to perform automated security tests.
Combined with an automated build pipeline, security tests that fail when a vulnerability is present will prevent vulnerabilities from being re-introduced at a later date by developers.
Since jail is real, I’ll be demonstrating this suite using Google Gruyere’s sandbox.
Sometimes real world exploit scenarios in web applications involve multiple steps. Many vulnerabilities require authentication tobe exploited. Thankfully, Postman makes this easy using its collections test runner.
First, we need to log in and get the authentication cookie.
Postman allows you to set environment variables by using the pm.environment.set function. This is very useful for test cases that are dependent on the responses of previous requests, such as authentication headers and account numbers. Thanks to this, tests can be more dynamic and cut down on the use of hardcoded data.
Cookies can be managed by setting the Cookie header to the “cookie” Postman environment variable. Doing this on each request will automatically include the correct value.
Next, we submit the request with the payload. The input should be validated in this case to ensure it doesn’t contain dangerous HTML payloads while still allowing harmless HTML through.
Writing security tests using Postman allows for a test suite that will pass when vulnerabilities are fixed. It is important to note that a passing test suite does not mean that the vulnerability has been patched fully, so manual testing with other vectors is still necessary. Creating a test case to reproduce the additional vector will help the developers create more secure software.
Newman and your Pipeline
To really see the benefits of automated Postman tests, it’s best to add them as a build step using your Continuous Integration build pipeline software. Newman allows you to run Postman test collections whenever code is pushed to your repository.
First, export both your environment and collection as JSON files. Then, simply tell Newman where your environment and collection are and run it.
Adding that command to your build pipeline will let Newman run your tests every build, and prevent regressions.