JSON Data Validation Levels and its Usage in Postman

JSON Data Validation Levels and its Usage in Postman

The most appropriate way to do that is through JSON Schema — the method of description of the structure of the JSON data.

Besides JSON Schema, each individual key/value pair can be checked for compliance with a number of criteria from the specification.

This criteria can be divided into validation levels:

  1. JSON validation — low-level check;
  2. Required keys;
  3. Data types;
  4. Default values;
  5. Required values;
  6. Additional criteria — high-level check.

Based on these levels you can adjust the depth of testing of your JSON data.

1. JSON validation

This is an initial check that answers the question: Is the body parsable?

Validation could be done by JavaScript’s standard method — JSON.parse() will throw an error in case of invalid JSON.

By the way, according to JSON documentation the empty object {} is a valid JSON.

2. Required keys

Does a JSON object contain required key/value pairs?

3. Data types

What data type should have the value of a given key? Number, string, boolean, array, object or null?

4. Default values

This point is rarely specified in documentation, but for some JSON keys you have to figure out what is considered the correct value.

For example: suppose you get the response body:

{
name: "Marcus Aurelius",
school: "Stoicism"
}

But, what if you get a philosopher without a particular school? What should be the default value? school: "" or school: null or the key should be missing?

5. Required values

It could be anything related to documentation: formats of the dates, numerical boundaries, etc.

A good question to ask at this level: Could the value be undefined? (preferably — not).

Another example: suppose you get the response body:

{
name: "Marcus Aurelius",
school: "Stoicism",
occupation: ["philosopher", "emperor"]
}

If the required value of occupation key is philosopher, then each body should be checked for that the array occupations[] includes an item "philosopher".

6. Additional criteria

This level is strongly tied up to specification and can not be universal for equivalent requests.

For example: suppose you get the response body:

{
name: "Marcus Aurelius",
school: "Stoicism",
reign: [161, 180]
}

Exactly for this body the array reign[] must include only 161 and 180 values. But for other cases, this particular check will be incorrect.

So, if you decide not to engage in high-level validation checks (additional criteria or required values), then your test will be more universal and less prone to false positives. But otherwise, you are more likely to miss a bug. It is always a trade off.

Usage of validation levels

Each key/value pair in the response body could be checked both manually and automatically.

Sometimes, even if you do not need to write autotests for JSON validation, it is easier to write a script test than to validate the body by your own eyes. Postman test scripts are the best solution for such kind of tasks.

For the examples above I took a simple response from an OpenWeather API’s request: https://api.openweathermap.org/data/2.5/onecall?lat=40.1811&lon=44.5136&units=metric&exclude=minutely,hourly,daily,current,allerts&APPID={api_key}

{
"lat": 40.1811,
"lon": 44.5136,
"timezone": "Asia/Yerevan",
"timezone_offset": 14400
}

1. How JSON data validation levels MAY look like in a script

If you take each validation level and and blindly impose it on the data structure, the test script may look like this:

How JSON data validation levels MAY look like in a script
Tests passed

Such a script can be significantly improved by getting rid of redundant checks and refactoring the structure.

2. How JSON data validation levels SHOULD look like in a script

A more correct way is an individual checks of each value:

How JSON data validation levels SHOULD look like in a script
Tests passed

3. JSON data validation through JSON Schema

JSON Schema allows to test all validation levels at once!

Postman has a built-in tool for validation JSON Schema — Tiny Validator. For using it, you just need to define you JSON Schema as an object:

Test passed

With a JSON Schema you can check the body in a fast and efficient way.

Unfortunately, in case of an error you will not get an idea what exactly broken:

Test failed

Actually, Tiny Validator is an outdated tool. If you are going to use schema validation in autotests, it is recommended to choose Avj.

If your response body consists of XML format, all definitions of validation levels can be applied to it too.

Further reading:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store