Scriptless Test Automation | Advanced Response Validation Tutorial (Part 1)

There are many tools out there which offer Scriptless Test Automation, and I am pretty sure that they offer some great features and functionalities that one can benefit from. The only issue is that the lack of simplicity in the tool, itself, makes the usage so tiresome, that it will almost equal the efforts that are required in scripted test automation.

This article is the first of a series of articles under the topic, “Advanced Response Validation Tutorial”. This series of articles is to demonstrate how you can validate your API responses using vREST NG, in a very advanced way. The series will contain all the basics that you need to understand in order to perform Advanced Response Validation using vREST NG.

What does vREST NG provide?

vREST NG provides you with Assertions (similar to Test Oracles in other tools/frameworks). These assertions are nothing but conditions that you can apply to your test case, which will determine the success or failure of your test case, once you run it. The best part of it is that these assertions are Scriptless. This means that the hassle of writing test scripts is diminished.

These assertions consist of another unit, known as Response Validators. Now, as the name suggests, Response Validators are used to validate the API Response in certain ways. Response Validators in vREST NG allows you to apply comparative conditions at very specific locations in your API Response (but we will talk about that in another blog post).

Let’s see what can you achieve with these Scriptless assertions and Response Validators…

Scriptless Assertions & Response Validators

vREST NG’s assertions and response validators allow you to validate various response attributes like,

  • Status Code,
  • Response Headers,
    • Useful to validate the response header’s values.
  • Response Time,
    • Useful to validate the API’s performance. If an API is not returning response in pre-defined time period then APIs implementation can be improved.
  • Response Content (Text Body or JSON Body or XML Body)
    • here Text body assertions can be applied to any type of response text content.
Example of vREST NG Assertions

Status Code

The most basic assertion that judges, if the test case will pass or fail, is the Status Code assertion. You can see in the above screenshot, how you can apply a Status Code assertion.

It provides 6 operators to apply as conditions:

  • Equal to number: This allows you to check if a Status Code is equal to a certain number, or not.
  • Does not equal to number: This allows you to check if a Status Code is not equal to a certain number, or not.
  • Less than: This allows you to check if a Status Code is less than a certain number, or not.
  • Less than or equal to: This allows you to check if a Status Code is less than or equal to a certain number, or not.
  • Greater than: This allows you to check if a Status Code is greater than a certain number, or not.
  • Greater than or equal to: This allows you to check if a Status Code is greater than or equal to a certain number, or not.

Response Time

This assertion allows you to set certain conditions on Response Time(ms) of your test case.

It also provides 6 operators to apply as conditions:

  • Equal to number: This allows you to check if a Response Time is equal to a certain number, or not.
  • Does not equal to number: This allows you to check if a Response Time is not equal to a certain number, or not.
  • Less than: This allows you to check if a Response Time is less than a certain number, or not.
  • Less than or equal to: This allows you to check if a Response Time is less than or equal to a certain number, or not.
  • Greater than: This allows you to check if a Response Time is greater than a certain number, or not.
  • Greater than or equal to: This allows you to check if a Response Time is greater than or equal to a certain number, or not.

JSON Body

JSON Body assertion allows you to apply specific assertions on any part of a json response. In this assertion you have to provide the property to track the json element. For eg, user.username

It provides 18 operators to apply as conditions:

  • Equal to: It checks if the value of the given property is equal to expected value.
  • Does not equal to: It checks if the value of the given property is not equal to expected value.
  • Is empty: It checks if the value of the given property is empty.
  • Is not empty:It checks if the value of the given property is not empty.
  • Contains: It checks if the value of the given property contains the expected value.
  • Does not contain: It checks if the value of the given property does not contain the expected value.
  • Matches with regular expression: It checks if the value of the given property matches with the expected value which can be entered as a regular expression. (Used in the case of dynamic values.)
  • Is a number: It checks if the value of the given property is a number.
  • Is a boolean: It checks if the value of the given property is a boolean.
  • Equal to number: It checks if the value of the given property is equal to a certain number.
  • Does not equal to number: It checks if the value of the given property is not equal to certain number.
  • Less than: It checks if the value of the given property is less than the expected value.
  • Less than or equal to: It checks if the value of the given property is less than or equal to the expected value.
  • Greater than: It checks if the value of the given property is greater than the expected value.
  • Greater than or equal to: It checks if the value of the given property is greater than or equal to the expected value.
  • Has key: It checks if the value of the given property has a JSON key or not.
  • Has value: It checks if the value of the given property has a certain value assigned to a JSON key.
  • Is null: It checks if the value of the given property is null.

XML Body

XML Body assertion allows you to apply specific assertions on any part of a XML response. In this assertion you have to provide the property to track the XML element. For eg, user/username

It provides 18 operators to apply as conditions:

  • Equal to: It checks if the value of the given property is equal to expected value.
  • Does not equal to: It checks if the value of the given property is not equal to expected value.
  • Is empty: It checks if the value of the given property is empty.
  • Is not empty:It checks if the value of the given property is not empty.
  • Contains: It checks if the value of the given property contains the expected value.
  • Does not contain: It checks if the value of the given property does not contain the expected value.
  • Matches with regular expression: It checks if the value of the given property matches with the expected value which can be entered as a regular expression. (Used in the case of dynamic values.)
  • Is a number: It checks if the value of the given property is a number.
  • Is a boolean: It checks if the value of the given property is a boolean.
  • Equal to number: It checks if the value of the given property is equal to a certain number.
  • Does not equal to number: It checks if the value of the given property is not equal to certain number.
  • Less than: It checks if the value of the given property is less than the expected value.
  • Less than or equal to: It checks if the value of the given property is less than or equal to the expected value.
  • Greater than: It checks if the value of the given property is greater than the expected value.
  • Greater than or equal to: It checks if the value of the given property is greater than or equal to the expected value.
  • Has key: It checks if the value of the given property has a JSON key or not.
  • Has value: It checks if the value of the given property has a certain value assigned to a JSON key.
  • Is null: It checks if the value of the given property is null.

Text Body (Other types)

If you assertions are of any different type, then you can apply the Text Body assertion.

It provides 17 operators to apply as conditions:

  • Equal to: It checks if the value of the given property is equal to expected value.
  • Does not equal to: It checks if the value of the given property is not equal to expected value.
  • Is empty: It checks if the value of the given property is empty.
  • Is not empty:It checks if the value of the given property is not empty.
  • Contains: It checks if the value of the given property contains the expected value.
  • Does not contain: It checks if the value of the given property does not contain the expected value.
  • Matches with regular expression: It checks if the value of the given property matches with the expected value which can be entered as a regular expression. (Used in the case of dynamic values.)
  • Is a number: It checks if the value of the given property is a number.
  • Is a boolean: It checks if the value of the given property is a boolean.
  • Equal to number: It checks if the value of the given property is equal to a certain number.
  • Does not equal to number: It checks if the value of the given property is not equal to certain number.
  • Less than: It checks if the value of the given property is less than the expected value.
  • Less than or equal to: It checks if the value of the given property is less than or equal to the expected value.
  • Greater than: It checks if the value of the given property is greater than the expected value.
  • Greater than or equal to: It checks if the value of the given property is greater than or equal to the expected value.

Conclusion

What you have seen above is just a glimpse in theory. Once you start using vREST NG, you will realize that you don’t actually need to write code most of the time. After writing either one or two vREST NG Test Cases, you will get the hold of it, you will see a great change in your Testing Efforts.


Check out the next post, Default Validator | Advanced Response Validation Tutorial (Part 2)