The Swagger Compliance assertion verifies that the response corresponds with the specified definition. The assertion supports the following specifications:
-
Swagger 2.0 (also known as OpenAPI 2.0)
-
OpenAPI 3.0.0 and 3.1.0
Availability
| In... | Checks... | To learn more... |
|---|---|---|
| Functional tests | The response. | See Working With Assertions in Functional Tests. |
| Virtual services | The request. | See Assertions in Virtual Services. |
Create an assertion
Follow these steps:
Click the image to enlarge it.
-
Open a test step.
-
Click Add assertion.
In the New Assertions dialog, search for the Swagger Compliance assertion or select it manually in the Compliance, Status and Standards category.
Follow these steps:
Click the image to enlarge it.
-
Open the virtual service.
-
Select the operation you want to assert.
-
Click
in the Assertions panel.
In the New Assertions dialog, search for the Swagger Compliance Assertion assertion or select it manually in the Compliance, Status and Standards category.
 |
You cannot apply this assertion to the entire virtual service, you can apply it only to individual operations. |
Setting up properties
-
In the Swagger URL field, specify the file name or URL of the desired OpenAPI or Swagger specification.
If the definition's URL requires authentication, you will be prompted to enter credentials.
Click the image to enlarge it.
-
If you enable the Strict Mode option, the assertion will fail if the definition does not contain the appropriate response. If you disable this option, the assertion passes if the response code is not specified in the definition.
Remarks
-
How the assertion works:
In functional tests
-
The assertion gets a response code. Then, it searches for the corresponding status code specified in the definition and checks if the response has an appropriate content-type.
If the definition specifies the response body, the assertion verifies if the response body coincides with the specified schema.
-
(Only for Open 3.0.0 specifications) If the response status code is not defined in the definition, the assertion compares the response against the
defaultresponse.Currently, the assertion does not support the range of responses. -
By default, if the assertion cannot find an appropriate HTTP status code, it passes. If you want the assertion to fail in such cases, enable the Strict mode option.
In virtual services
-
The assertion checks whether the request has the appropriate content type.
If the definition specifies the request body, the assertion checks whether the request body coincides with the specified schema.
-
-
When the assertion runs for the first time, ReadyAPI loads the definition into an internal cache. During the following runs, the assertion uses a cached version of the definition. ReadyAPI clears the cache when it is closed.
-
The JSON Schema Validation: A Vocabulary for Structural Validation of JSON is automatically used to validate any RegEx expressions included in your API definition file. That schema uses the ECMA-262 standard for RegEx encoding. The usage of that schema is a standard and it is not controlled by ReadyAPI, as per the official documentation linked above.
It does now follow the Glossary | ReadyAPI Documentation RegEx encoding so it does not follow the Java Regular Expressions encoding. As a consequence, it does not support Unicode encoding for RegEx.
Other schema compliance assertions
Add other schema compliance assertions:
-
JSON Schema Compliance Assertion – Verifies that the JSON body of the response complies with a JSON schema.
-
Schema Compliance Assertion – Verifies that the response complies with a .wsdl or .wadl schema.