Page Comparison

In vREST, assertions can further invoke validators to validate the test case responses. A response validator is simply a JavaScript function. A test case passes if the assigned response validator returns true otherwise it fails. 

In this article, we will cover:

1. The different types of validators
2. Benefits of using Default Validator over multiple JSON Body assertions
3. Various Response Validation Scenarios

Types of Validators

vREST provides the following default response validators, and also provide you a way to define your own custom validator.

1. Default Validator validates the expected and actual responses (response body) for exact match. If the value doesn't match, it simply fails the test case. We need to define Expected Body for the test case, if we choose this. Any variables in expected body are first replaced and then provided to the validator for response validation. 
    
2. Default Schema Validator validates the schema of actual response instead of checking for exact content match. We need to define Expected Schema for the test case, if we choose this. If we use this validator, then we don't need to define the Expected Body. 
   
   
3. Custom Validator validates the actual response by your own way. Most of the cases of response validation can be handled with the above default validators. However, you may define your own custom validators for customized response validation. vREST also provides the Javascript code for the default validators in Project Configuration > Response Validators section for reference on how you can define your own custom validator. A custom validator can be created by clicking on the "New Validator" button as shown in the image below:
   
   

A response validator function will get the following input parameters:

1. testcase

   First parameter is test case, having all the details of a test case which has been provided in the test cases tab.

2. response

   Second parameter is actual response of the HTTP request. It is a JSON object with the following keys:
   1. headers: HTTP Response headers retrieved
   2. actualResults: HTTP Response result retrieved. It is also a JSON object with the following keys:
      1. content: (String) Actual HTTP Response body
      2. resultType: (String) Content type of HTTP Response body

3. methods

   Third parameter is methods object. This parameter contains the following predefined utility methods:
   1. compareJSON: Compares two JSON objects property by property and also provides special checks for given properties by using "customJSONPropertyChecker" parameter.
   2. validateJSONSchema: Validates JSON objects using JSON Schemas. For more information, please see the source code at the following link:
      1. Source: https://github.com/kriszyp/json-schema/blob/master/lib/validate.js
      2. Version: 0.2.2

Benefits of using Default Validator over multiple JSON Body assertions

If you understand well, how Default Validator works, then in majority of cases, you don't need to define any other JSON Body assertions. You need to define the Expected Body if you choose Default Validator in the Text Body Assertion. Suppose, I want to validate an API which returns the following response. We are taking a simple response here, how you can validate the complex responses through Default Validators are covered later in this article.

{
  "key1": "value1",
  "key2": "value2",
  "key3": {
    "keya": "valuea",
    "keyb": "valueb",
    "keyc": "valuec"
  }
}

Now, if you don't want to validate the response with Default Validator, but instead you have defined the following JSON Body assertions to validate the response.

With Default Validator, you can convert these multiple JSON Body assertions into one assertion, but you need to set the Expected Body in this case.

So, benefits of using this approach are:

1. Easier to Define
   Even if you don't know the expected response body in advance then just set the empty object ({}). When you execute this test case, you will have an option to copy actual response body to expected response body.
2. Easier to maintain
   If your test case response changes in future then you can use function "Copy Actual to Expected" to update the expected body after reviewing the Diff Report with a single click.
3. Easier to visualise changes
   Diff report is more compact and pretty way to visualise the test case failures.

Response Validation Scenarios:

Let us see, how various types of responses can be validated in vREST.

1. My API returns the static response.
2. I just want to validate the schema of my response, not the actual content.
3. My API returns some dynamic properties like _id, createdOn etc. and I want to ignore them during response validation.
4. My API returns a very large response and I am interested in validating only a small part of my API response.
5. My API returns some response in which some part of the response can be obtained from the responses of previous test cases.
6. My API returns dynamic response and none of the above fit to my needs.

Scenario 1: My API returns the static response.

If your API returns the static response, then just set the Expected Body with the static response and Expected Status Code.

Let us suppose, your API returns the following static JSON response,

{
  "vREST": [
    "A simple and intuitive tool to quickly validate your REST APIs.",
    "Deliver zero defect web applications with very less effort in API testing.",
    "Works in hosted mode (http://vrest.io).",
    "No skilled resources required to validate your web application.",
    "Quickly generate documentation for your API specifications.",
    "De-couple your frontend implementation with backend implementation with easy to use Mock Server.",
    "Ease of maintenance over a span of releases."
  ]
}

For such scenarios, simply specify your static response body in Expected Body and set the Expected Status Code also as specified in the following image. Validator used for this scenario is "Default Validator".

 

Scenario 2: I just want to validate the schema of my response, not the actual content.

Let us consider a scenario, where response contains random data (unpredictable data) or list of some unordered items. Only the schema/structure of the response is predictable. In such scenario, Default Schema Validator can be used. 

e.g. let's suppose an API returns a list of random quotes. Since it returns a random list, so we cannot predict the outcome of this API. But what we know is the structure/schema of this response.

In the following response,

1. Every item in the quotes list have fields like "quote", "author", "designation", "organization".
2. And each field is of type String.

{
  "quotes": [
    {
      "quote": "Stay hungry, stay foolish.",
      "author": "Steve Jobs",
      "designation": "Co-founder, Chairman & CEO",
      "organization": "Apple Inc."
    },
    {
      "quote": "If you're changing the world, you're working on important things. You're excited to get up in the morning.",
      "author": "Larry Page",
      "designation": "Co-founder & CEO",
      "organization": "Google"
    },
    ...
  ]
}

For using Default Schema Validator, first we need to define the Expected Schema of the response as shown in the following image. We can use an external tool http://jsonschema.net to automatically generate the schema of our response.

Note:

• If you use Default Schema Validator, you need to define the expected schema of the response.
• We do not own the utility hosted at http://jsonschema.net. The link provided here is just for convenience in writing JSON schema.
• The above utility provides you the basic JSON schema of your response plus some constraints. If you want to provide additional schema constraints, I recommend you to read about JSON Schema.

Scenario 3: My API returns some dynamic properties like _id, createdOn etc. and I want to ignore them during response validation and also I want to validate some of the properties with regular expression.

Suppose, If your API which creates a resource on the server and returns some dynamic properties like _id, createdOn etc. And you want to ignore these dynamic properties during the response validation and also you want to check the email property with email regular expression. In such scenario, Default Validator can be used.

e.g. Let us suppose, the API returns the following response:

{
  "_id": "536493015f56452a03000010",
  "createdOn": "2014-05-03T06:56:01.134Z",
  "name": "John Doe",
  "email": "john.doe@example.com",
  "designation": "Chief Technical Officer",
  "organization": "Example.com",
  "country": "India",
  "aboutMe": "My name can be used as a placeholder name and I don't have any identity.",
  "twitterId": "fake.john.doe",
  "facebookId": "fake.john.doe",
  "githubId": "fake.john.doe"
}

{
  "key1": "value1",
  "key2": {
    "key2.1": "value2.1",
    "key2.2": "value2.2",
    "key2.3": "value2.3",
    "key2.4": "value2.4"
  },
  "key3": "value3",
  "key4": "value4"
}

Note: 

• The above scenarios are also covered in our online demo available at Response Validation Demo
• Variables plays an important role in response validation. See also Variables