Automating Response Validation With Assertions In Postman

In This Tutorial, we will Understand the Concept of Assertions in Postman Requests With the Help of Examples:

Assertions make Postman a great utility tool to create integration tests for rest API endpoints. Depending on the output of these assertions, we can see if a test can either pass or fail.

Postman uses the Chai assertion library for creating assertions. It’s based on the BDD style of assertions which make it highly readable and understandable.

=> Visit Here To See The Postman Training Series For All.

Automating Response Validation With Assertions

An example of such an assertion is given below.

pm.expect(response).to.not.equal(null)

Looking at the above assertion/statement, anyone can easily make out that this assertion is trying to assert that the response is not null. Similar to this, the Chai library provides a lot of BDD operators.

Postman has a lot of prebuilt scripts to create basic assertions like checking the response to be non-null, validating the HTTP status code of the request, etc.

Here is a Video Tutorial:

Creating The First Assertion

In this section, let’s get started by writing a simple assertion. For example, verifying the status code of the request being executed, and then running the request and validating the result.

First, let’s try to focus on a few key concepts of Postman as a tool in terms of how the execution environment is configured? What objects are exposed by Postman that can be used to add assertions on etc?

Understanding The Postman Sandbox

Postman sandbox is the actual JS execution environment in the context of which the Postman application or the Chrome addon runs.

It exposes the Postman object named ‘pm’ with which we can access various things like:

• Request and response parameters.
• Set and get environment variable and global variables.
• Get request and response headers.
• Get cookie values.

The ‘pm’ Object

pm is the object that contains the script that’s running in the Postman sandbox. It allows you to get request context and response context as well once the request is executed.

It allows you to access requests and responses as read-only objects and helps in using different kinds of Postman variables by getting or setting their values.

Tests For Postman Request

To create an assertion for a given request, you first need to have a test or expectation against which you would assert that. You can contrast similar to the Unit test analogy, where we follow the 3As rule for each test i.e. Arrange, Act and Assert.

Similar to that, in Postman:

#1) Arrange is simply the request execution with all the variables like URL, Request path, Request body set properly.

#2) Act is actually executing the request through the Postman console (or through any command-line utilities that support such execution)

#3) Assert is validating an exception and is done inside the “Tests” tab for a request.

Please follow the below steps to write the HTTP Status code verification assertion.

#1) We will be using a sample hosted API for writing our assertion. Here is the sample endpoint against which we will write tests and add assertions.

#2) Open Postman and create a GET request for the above URL.

#3) Once the request is configured, try clicking “Send” to ensure that the request is correctly set up and you are getting some response.

#4) Now, let’s try adding a test to this request. The first one will be to just check whether the requests return an HTTP 200 OK Status code. For that we can use Postman’s easy templates to validate, else we can simply type-in as below.

pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

In the above code snippet, let’s try to break it into 2 components i.e. test and assertion and try understanding each of them one by one.

• pm.test() is a closure function that allows you to write tests for a Postman request that’s being executed. Please note for writing multiple tests for the same request, there should be multiple blocks of pm.test() closure or function.
• pm.response.to.have.status(200) is the actual assertion that is trying to validate the response to have a status code of 200. Refer to the pm object which we are using to create an assertion.
• Please note that there are multiple libraries supported for assertions in Postman. Using pm.expect() as a generic assertion library we can make use of chaiJs library assertions. For example, if we want to add an assertion that checks the status code as one of 200 or 201, then we can simply write it as shown below:

pm.test("Status code is 200", function () {
pm.expect(pm.response.code).to.be.oneOf([201,202]);
});

#5) Once the test is added, let’s try to execute this request again, and see the results of the test. Open the “Tests” tab in the response section and see the test/assertion validation message.

#6) Let’s try this test again, but this time, we will try to fail this test by updating the expectation. For example, HTTP 202 rather than HTTP 200.

pm.test("Status code is 202", function () {
pm.response.to.have.status(202);
});

#7) Once done, try hitting the request again and see the result. The test should fail and there should be an appropriate error message displayed.

Advanced Assertions

In this section, we will go deeper with assertions and see how we can write more advanced assertions like – validating a response body against a JSON schema, asserting the value of a particular field in the response, etc.

Validating A JSON Field In Response

In these types of assertions, we would typically validate a particular field in response to a predefined value.

For example, if our API endpoint returns the below JSON response:

{
  "page": 1,
  "per_page": 6,
  "total": 12,
  "total_pages": 2,
  "data": [
    {
      "id": 1,
      "email": "george.bluth@reqres.in",
      "first_name": "George",
      "last_name": "Bluth",
      "avatar": "https://s3.amazonaws.com/uifaces/faces/twitter/calebogden/128.jpg"
    }
  ]
}

Now, we want to assert the value of “per_page” field to always equal to 6, and we can write an assertion as below:

pm.test("value of per_page field is 6",function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.per_page).to.eql(6);
});

As you can see above, we’ve first stored the JSON response of the request in the jsonData local variable and then added the assertion in the pm.expect() block.

Validating JSON Schema

Similar to the above, now if we want our response JSON to adhere to a particular JSON schema, we can make use of Postman assertions and ensure that schema validation can be done against the actual response.

For illustration, we will be using an endpoint(click here for endpoint) for schema validation. To get the JSON schema for the response of this endpoint, simply use that JSON to create schema online. There are different libraries, that allow us to extract our schema from an existing JSON. For more details, refer here.

Once the schema for the JSON response is extracted, let’s see how we can go about writing schema validation.

var schema = {
 "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "data": {
      "type": "object",
      "properties": {
        "id": {
          "type": "integer"
        },
        "email": {
          "type": "string"
        },
        "first_name": {
          "type": "string"
        },
        "last_name": {
          "type": "string"
        },
        "avatar": {
          "type": "string"
        }
      },
      "required": [
        "id",
        "email",
        "first_name",
        "last_name",
        "avatar"
      ]
    }
  },
  "required": [
    "data"
  ]
};
var jsonResponse = pm.response.json();
pm.test('Schema is valid', function() {
  pm.expect(tv4.validate(jsonResponse, schema)).to.be.true;
});

Let’s try to understand the assertion in detail.

#1) Firstly, we try to store the schema for the JSON in a local variable.

#2) We now store JSON from the actual request execution through pm object.

#3) Now, we add an assertion in pm.expect() block, and use the TinyValidator library to validate JSON response against the given schema. The TinyValidator library is a part of the Postman Sandbox environment itself.

Tips & Notes

Please note that:

• A single Postman test can contain as many assertions as you would like to have. They are exactly analogous to the unit testing world where we can have multiple assertions in a single unit test.
• In a single test, if one assertion fails, subsequent assertions will not be validated i.e. suppose a test had 5 assertions and for example, 3rd assertion did not pass, then the 4th and 5th assertions will not be evaluated and the Postman test will be marked as failed.
• Unlike assertions, if a test fails, the rest of the tests are still executed and each test is either marked Pass or Fail once the request execution is complete.

Pros & Cons Of Assertions

Writing tests/assertions with the Postman provides a lot of power and flexibility in the hands of developers or QA who is working on performing end to end test for a particular API endpoint.

But, just like the saying “too much of anything is not good”, too much of granular assertions for the response received can sometimes result in the Postman tests being flaky, as a slight change to dev code will make the tests fail.

Thus, simply said, before adding a test into Postman, it is wise to understand the implication of the test/assertion being added, and we must ensure, that only absolute essential fields or validations should be covered as a part of assertions to avoid flakiness in the test results for future executions.

Conclusion

This tutorial touched upon the concept of assertions and tests in Postman requests. This is a powerful feature and could help to create some robust and fast integration tests thereby making regression for API endpoints easier.

Having said that, it should be kept in mind that we are not testing very granular or low-level details inside an API response, as that might cause these tests to be flaky.

This, in the long run, causes a dent in the importance of these tests as people might start thinking that these tests are not deterministic and even the slightest dev change is sufficient to break these.

Suggested reading =>> Laravel Forms and Validation Rules

=> Explore The Simple Postman Training Series Here.