The Smart Assertion checks both the message content and the metadata such as headers, status codes, and parameters in accordance with the predefined set of rules.
| Note: | The Smart Assertion supersedes the Message Content, Valid HTTP Status Codes, Invalid HTTP Status Codes, HTTP Header Equals, and HTTP Header Exists assertions. They are also easier to setup and configure. The assertions will continue to be available, but we recommend transitioning to Smart Assertions. |
To use this assertion, you need a ReadyAPI Test Pro license. If you do not have it, request it on our web site or start a trial.
Availability
This assertion is available in multiple ReadyAPI applications. Depending on the application, it validates the following data:
| In... | Checks... | To learn more... |
|---|---|---|
| The request or response contents. | See Working With Assertions in Functional Tests. | |
| Security tests | The response contents. | See Security Assertions. |
| Virtual services | The request contents. | See Assertions in Virtual Services. |
Create an assertion
Select a test step and click the Smart Assertion button.
 |
To create an assertion based on a response, send the request at least once. |
Click the image to enlarge it.
–or–
Follow these steps:
Click the image to enlarge it.
-
Open a test step.
-
Click Add assertion.
In the New Assertions dialog, search for the Smart Assertion assertion or select it manually in the Property Content category.
Follow these steps:
Click the image to enlarge it.
-
Open a security test.
-
Click Response Assertion next to any scan.
-
Click
in the Assertions panel
In the New Assertions dialog, search for the Smart Assertion assertion or select it manually in the Property Content category.
Follow these steps:
Click the image to enlarge it.
-
Open a virtual service.
-
Open the Assertions drop-down panel.
-
Click
in the Assertions panel
In the New Assertions dialog, search for the Smart Assertion assertion or select it manually in the Property Content category.
Set up properties
Select assertion type
After adding the assertion, specify its type:
-
Received Data – The assertion will verify the payload of the request, similarly to the deprecated Message Content assertion.
-
Received Metadata – The assertion will verify the metadata of the request; depending on the protocol, those can include headers, the HTTP status code, or Kafka partition and key values. Use
and 
to add and remove the metadata to verify.
Click the image to enlarge it.
|
After changing the assertion type, all the entered data will be lost, and you will have to reconfigure the assertion. |
| Note: | The Smart Assertion can verify either the data or the metadata. To assert both, add another Smart Assertion. |
Configure assertion parameters
When you add the assertion, ReadyAPI configures the default settings for it based on the last received response (or the selected message, in case of Kafka). If you are satisfied with the settings, click Save. Otherwise, change the assertion settings:
Click the image to enlarge it.
-
In the Active column, select the check boxes next to the nodes you want to verify.
-
In the Condition column, select the comparison operator from the drop-down list.
-
Specify the value you need in the Valid Value column.
Tip: You can see the value that the node had in the last response in the Current Value column. To copy the current value, select the row and select Ctrl+C (on Windows) or Command+C (on MacOS). -
If you want the comparison to be case-sensitive, select the check box in the Case Sensitive column.
Click Load from Schema to load values from the associated protobuf schema. This option is available only for gRPC and Kafka requests.
Click Load from Transaction to reload the values from the last response you have got.
To remove all the selected operators and the expected values, click Clear.
| Note: | In ReadyAPI, when using Smart Assertion inside structured data (such as JSON or XML) instead of a direct string comparison,
if the value being asserted is non-existent and results in an empty string (""),
the assertion will pass because an empty string is always present in the response.
This is expected behavior. Ensure your tests are configured to handle empty strings properly to avoid false positives. |
Comparison operators
The assertion uses the following comparison operators:
| Operator | Description |
|---|---|
| Equals | Checks whether the actual node value equals the expected value. |
| Checks whether the actual node value does not equal the expected value. | |
| Equals (One of) | Checks whether the actual node value equals one of the expected values specified in the comma-separated format. |
| Checks whether the actual node value does not equal any of the expected values specified in the comma-separated format. | |
> |
Checks whether the actual node value is greater than the expected value. For non-numeric values it always fails. |
< |
Checks whether the actual node value is less than the expected value. For non-numeric values it always fails. |
>= |
Checks whether the actual node value is not less than the expected value. For non-numeric values it always fails. |
<= |
Checks whether the actual node value is not greater than the expected value. For non-numeric values it always fails. |
| Exists | Checks whether a node exists in the received message. |
| Does not Exist | Checks whether a node does not exist in the received message. |
| Is Empty | Checks whether a node exists and is empty in the received message. |
| Is not Empty | Checks whether a node exists and is not empty in the received message. |
| Contains | Checks whether a node contains the expected value. |
| Does not Contain | Checks whether a node does not contain the expected value. |
| Matches (regex) | Checks whether the actual value matches the specified regular expression. |
| Is Data Type | Checks whether the data type of the current value matches the expected data type. |
Other assertions for content
Add more assertions for response and request contents:
See Also
Property Content Assertions
Contains Assertion
Not Contains Assertion