Assertions are validation rules applied to test results that check how your target web service performs. In ReadyAPI Test tests, you use assertions to verify response codes, response headers, individual values in response bodies, request execution time and to do other checks. The test runner runs assertions after a test step (request) is over.
Example 1 – SLA Assertion
Let’s create an assertion that will check if the tested web service responds within a predefined time limit:
In ReadyAPI Test, select GET Request in the Navigator panel and click Add Assertion:
In the dialog, select the SLA category on the left and then Response SLA on the right, and click Add:
Note: SLA stands for service-level agreement. This term typically means the maximum time it takes for an operation to execution. Of course, this time should be acceptable for users.
After you click Add in the Add Assertion dialog, ReadyAPI displays the dialog box where you can configure assertion parameters. This dialog box looks differently for different assertions. The image below shows how it looks for the Response SLA assertion.
1000milliseconds as the maximum allowed response time for our request. Enter
1000and click OK:
Now, if the request takes longer than the specified number of milliseconds to complete, the assertion will trigger, and the test will fail. If the execution time is less than or equal to the specified value, the check will pass.
The new assertion is avalable in the Assertions panel:
If the request editor has response data, the assertion will be applied immediately. This is what we have in our case – we ran the request earlier and have some response by now:
ReadyAPI will re-apply assertion every time it gets fresher response data.
As you can see, in our case, the assertion failed because the request executed for longer time than 1 second. To change the time limit, double-click the assertion in the Assertions page and enter a larger value in the subsequent dialog:
Tip: You can add Response SLA and some other assertions to requests by using the New Functional Test wizard.
Example 2 – Check Response Contents
Now let’s see how you can verify response data. The sample response body has the JSON data format, so we will create an assertion for JSON data:
Make sure the request has a response. If it doesn't, click to send a request and get a response. See Run individual requests.
On the Assertions panel, click to create another assertion.
In the subsequent dialog, select the Property Content category on the left and the JsonPath Match assertion on the right and click Add:
This will invoke the assertion properties dialog.
In the dialog, you need to enter a JSONPath expression that will extract some field from the response body and the expected value of this field:
You can either type the desired expression, or click Select node on the toolbar and pick a value visually in the subsequent dialog. Let’s do this. Click , select the name field of the first array item in the following dialog and click OK:
The JSONPath Expression field now contains the selector, and Expected Result contains the value extracted from the current response data:
Click Save to store the changes.
Since we have response data, the assertion will be applied immediately and you will see its results in the Assertions page:
Now, if the response changes, the assertion will trigger and the test step will fail.
We would like to note once again that the described Select node command works only if the editor has some response data. That is, you need to run the request first and receive a response. In our case, it works because we ran the request on the previous step of the tutorial.