Schema Validation | Advanced Response Validation Tutorial (Part 3)

Schema Validation is something that is the first thing that comes to mind when it comes to the structural validation of your API’s responses. There are multiple ways of validating your API’s response and one of them is the schema validation.

If you are not familiar with the concept of a Schemas and how to validate your API’s responses against a Schema, then don’t worry you have landed in the right place. Firstly, let’s try to understand the most basic question of all…

What is a Schema?

To be put in the simplest form, a schema is nothing but a specification, on the basis of which a piece of data, written in any format (like, XML, JSON), is structured. It is a kind of document that defines the expected data type and format of each field of your data.

The only characteristic of a schema that makes it so useful is that it exists in both Machine-Readable and Human-Readable format. Thus it is a kind of document that can be understood by you and also by some software. So, what does this imply, then?

This means that if you have a schema for your data, then you have the opportunity to validate your data against this schema. Let me give you an example of whatever you have just read.

Let’s say that we have the following JSON data:

{
  "checked": false,
  "dimensions": {
    "width": 5,
    "height": 10
  },
  "id": 1,
  "name": "A green door",
  "price": 12.5,
  "tags": [
    "home",
    "green"
  ]
}

Then we can say that the following is the schema of the data above:

{
  "definitions": {},
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://example.com/example.json",
  "type": "object",
  "title": "The Root Schema",
  "required": [
    "checked",
    "dimensions",
    "id",
    "name",
    "price",
    "tags"
  ],
  "properties": {
    "checked": {
      "$id": "/properties/checked",
      "type": "boolean",
      "title": "The Checked Schema",
      "default": false,
      "examples": [
        false
      ]
    },
    "dimensions": {
      "$id": "/properties/dimensions",
      "type": "object",
      "title": "The Dimensions Schema",
      "required": [
        "width",
        "height"
      ],
      "properties": {
        "width": {
          "$id": "/properties/dimensions/properties/width",
          "type": "integer",
          "title": "The Width Schema",
          "default": 0,
          "examples": [
            5
          ]
        },
        "height": {
          "$id": "/properties/dimensions/properties/height",
          "type": "integer",
          "title": "The Height Schema",
          "default": 0,
          "examples": [
            10
          ]
        }
      }
    },
    "id": {
      "$id": "/properties/id",
      "type": "integer",
      "title": "The Id Schema",
      "default": 0,
      "examples": [
        1
      ]
    },
    "name": {
      "$id": "/properties/name",
      "type": "string",
      "title": "The Name Schema",
      "default": "",
      "examples": [
        "A green door"
      ],
      "pattern": "^(.*)$"
    },
    "price": {
      "$id": "/properties/price",
      "type": "number",
      "title": "The Price Schema",
      "default": 0.0,
      "examples": [
        12.5
      ]
    },
    "tags": {
      "$id": "/properties/tags",
      "type": "array",
      "title": "The Tags Schema",
      "items": {
        "$id": "/properties/tags/items",
        "type": "string",
        "title": "The 0 Schema",
        "default": "",
        "examples": [
          "home",
          "green"
        ],
        "pattern": "^(.*)$"
      }
    }
  }
}

You can try it out on your own, just go to jsonschema.net and you will be able to generate the schema of any JSON data. If the meaning of a schema is understood, then let’s move to the question that follows what we just saw.

Why do we need Schema Validation?

Now that you have understood, what a schema is, then let’s try to find out how it is used. Following are some of the most important uses of a Schema:

  • Reducing dependency in teams: This is one of the most important uses of a schema if you have a front-end and a back-end team working together. Having a schema for your API’s response helps the front-end teams to understand what kind of an API response they will be getting. On the basis of this, they can build the front-end and they do not have to be dependant on the back-end teams.
  • Validating API Responses: This is something that most of you must be familiar with. Schema validation is something that is used extensively in API Testing. The reason for this is that it helps you to verify if the API is returning the data in the structure that it should be returning.
    This workflow can be easily automated and can be helpful in creating a powerful test suite for your API Testing.

How can you perform Schema Validation?

Well, there are many ways of performing Schema Validation on your API’s response, but we will be seeing how you can do the same in vREST Desktop (follow this link to download vREST Desktop).

Once you are inside vREST Desktop, you can validate your API test case’s responses against JSON schema. You can define this JSON schema in,

  • Expected Schema sub-tab under Validation tab of each test case

  • And in Configuration >> Schemas section

Now we will see, how you may validate your test cases using JSON Schema definition.

1. Create test cases for your test application

  • Suppose we have two test cases for our example test application (Contacts Application).
  • One test case is validating the Add Contact API and another test case is validating the Update Contact API.
  • A sample screenshot is available below:

2. Validate those test cases via JSON Schema by defining the schema in Expected Schema Tab

  • Now you may validate these test cases by defining the expected JSON schema for the test cases responses.
  • You can define the JSON schema in Expected Schema sub-tab under Response Validation tab as shown below:

Expected Schema for Add Contact API

Expected Schema for Update Contact API

Note: Both APIs consumes the same JSON schema as the response structure of both APIs are same.

Now if you execute these two test cases, then both will pass. Now if we have hundreds of such test cases, then we will be defining the same schema in each test case. To overcome this issue we may define the schema globally in Project Configuration tab and re-use the same schema in our test cases.

3. Re-use the common schema by defining them in Configuration >> Schemas Section

In Configuration >> Schema Section, you may define all your schemas related to your APIs. Then you may use them in your test cases for response validation. In your test cases, you just need to refer the global definitions defined in Schemas section. This section is also useful when you import test cases via swagger definitions.

Let’s define our Contact schema in Configuration >> Schemas Section as shown below:

Now, we may use this schema in our test cases by referencing it in Expected Schema tab of our test cases as shown below:

Updated Expected Schema for Add Contact API:

Updated Expected Schema for Update Contact API:

Conclusion

By now, you are aware of what is a schema and how to perform Schema Validation, which is a major part of API Testing. There are other ways to structurally validate your API Responses, like validating them against Swagger Spec. Follow this link to understand how you can Import Swagger Spec into vREST Desktop, to generate test cases for your API.