TC Assertions sub tab

Assertions allows you to validate the test case response in a test run. If all the assertions of a test cases pass in a test run then test case will be marked as passed otherwise the test case will be marked as failed. Assertions can be defined in the Response Validation tab for a test case.

Against each assertion, you can specify the following attributes:

1. Source
   Source defines which response data you want to validate. Source can be anything from status code, response time, response headers, JSON body or text body.
2. Property
   This field further fine tunes the data received from the source. Suppose you have selected JSON body as source then in this field you can specify which JSON property you want to validate. For headers, you can specify the specific header name. This field is disabled for Status Code, Response Time and Text body. The value in this field can be any static value or dynamic value generated from variable or utility method.
3. Comparison
   This field defines the comparison operation you want to perform on source data. Operation includes various string, numeric, object comparisons. You can even call Default Validator, Default Schema Validator or any custom validators for the source "Text Body".
4. Expected Value
   This field allows you to specify the expected value for the source for which you want to compare. The expected value can be any static value or dynamic value generated from variable or utility method.

The detailed explanation of each assertion attribute is as follows:

Source

Assertions can be specified for the following sources for the test response:

1. Status Code
   Status Code assertion allows you to specify the expected status code of the test case response. You can apply assertions such as "equal to", "less than", "greater than" etc. on the expected status code.
2. Response Time
   This assertion allows you to specify that the test case response is returning within the prescribed time limits (in milliseconds). If the test case doesn't respond within the specified time limit then the test case will be marked as failed.
3. Header
   This assertion allows you to validate the response headers against the expected values and also provides the various string and numeric assertion comparisons on the expected values.
4. JSON Body
   This  assertion allows you to specify the JSON property path and expected value for that property and you can apply various string, numeric and object comparisons on the expected values.
5. XML Body
   This  assertion allows you to specify the XML path in Property column and expected value for that xml path and you can apply various string, numeric and object comparisons on the expected values.
6. Text Body
   This generic assertion is applicable for all types of responses including JSON also. You can apply various string and numeric comparisons on the response body. This assertion also allows you to validate your response body with Default Validator or Default Schema Validator or any custom validators you have defined.

Property

This field specify which source property you want to validate and this field can be specified for the following sources:

1. Header
   For source header, you can specify the header name which you want to validate, in this field. e.g. if you want to validate that the response header "Content-Type" contains the value "application/json" then you can define the following assertion:
   1. Source - Header
   2. Property - Content-Type
   3. Assertion Comparison - Contains
   4. Expected Value - application/json 

2. JSON Body
   For source JSON Body, you can specify the JSON property path which you want to validate, in this field. e.g. if you want to validate the value of nested property "keya" of the following JSON response, then you can define the following assertion:

   Sample Test Case Response

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

    

   1. Source - JSON Body
   2. Property - key3.keya
   3. Assertion Comparison - Equals
   4. Expected Value - valuea

3. XML Body
   For source XML Body, you can specify the XML path in the Property column which you want to validate. Consider the following XML response.

   <?xml version="1.0"?>
   <catalog>
      <book id="book1">
         <author>Author Name 1</author>
         <title>Book Title 1</title>
         <genre>Book Genre</genre>
         <price>50</price>
         <publish_date>2010-11-01</publish_date>
         <description>Book Description...</description>
      </book>
      <book id="book2">
         <author>Author Name 2</author>
         <title>Book Title 2</title>
         <genre>Book Genre</genre>
         <price>15</price>
         <publish_date>2010-12-13</publish_date>
         <description>Book Description ...</description>
      </book>
   </catalog>

   e.g. if you want to validate the author of first book, then you can define the following assertion:

   1. Source - XML Body
   2. Property - /catalog/book[1]/author/text()
   3. Assertion Comparison - Equals
   4. Expected Value - Author Name 1
   or if you want to validate the id attribute of first book then you can define the following assertion:
   
   1. Source - XML Body
   2. Property - /catalog/book[1]/@id
   3. Assertion Comparison - Equals
   4. Expected Value - book1 

Comparison

This field defines the operation you want to perform on source data. The following operations are applicable on various sources:

• Equals
  This operation returns true when actual value is equal to expected value. This operation first cast the actual value to string then performs a string comparison.
• Does not equal
  This operation returns true when actual value is not equal to expected value. This operation first cast the actual value to string then performs a string comparison.
• Is empty
  This operation returns true when the actual value is equal to blank string.
• Is not empty
  This operation returns true when the actual value is not equal to blank string. 
• Contains
  This operation returns true when the expected value is a substring of actual value. 
• Does not contain
  This operation returns true when the expected value is not a substring of actual value. 

• Matches with regular expression
  This operation matches the actual value against the regular expression specified in Expected Value field. e.g. For email regular expression, you may specify the expected value as shown below: 

  Email Regular Expression

  /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

• Is a number
  This operation returns true when the actual value is a number or can be casted to a number. 
• Is a boolean
  This operation returns true when the actual value is a boolean value or boolean string value "true" / "false".
• Equal to number
  This operation returns true when both the expected and actual values can be casted to number and are equal. 
• Does not equal to number
  This operation returns true when both the expected and actual values can be casted to number and are not equal. 
  
• Less than
  This operation returns true when actual value is less than the expected value specified. Both values are first casted to Number.
• Less than or equal to
  This operation returns true when the actual value is less than or equal to expected value specified. Both values are first casted to Number.
• Greater than
  This operation returns true when the actual value is greater than the expected value specified. Both values are first casted to Number.
• Greater than or equal to
  This operation returns true when the actual value is greater than or equal to the expected value specified. Both values are first casted to Number.
• Call Default Validator
  This operation calls the Default Validator to check the validity of the response body. For this assertion to work, you need to specify the Expected Response Body in the 'Expected Body' sub-tab.
• Call Default Schema Validator
  This operation calls the Default Schema Validator to check the schema of the response body. For this assertion to work, you need to specify the Expected Response Schema in the 'Expected Schema' sub-tab.
• Call <Custom Validator>
  This operation calls the Custom Validator of your choice to check the validity of the response body. You can optionally specify the Expected Response Body in the 'Expected Body' sub-tab.

Expected Value

This field allows you to specify the expected value for the source which you want to compare. The expected value can be of following types:

1. Static Value
   You can specify any static value in the Expected Value field. e.g. you want to validate that the API should return 200 as response status code. Then you can specify 200 in the Expected Value field.
2. Dynamic Value
   You can specify any dynamic value in the Expected Value field with the help of 
   1. Variables in the form of {{var1}}
      The value of variable 'var1' will be fetched from the variables extracted from previous test case responses or from Global Variables during verification of the assertion.
   2. Utility Methods in the form of {{sampleMethod(param1, param2)}}
      The expected value will be calculated from the utility method 'sampleMethod' defined in the "Project Configuration" >> "Utility Methods" section during verification of the assertion.