The Schema Compliance assertions check whether the last request or response follows the associated WSDL or WADL schema definition. This schema can be taken from the service definition, or inferred.
|If the schema contains a definition of one type, and the response returns another type, the Schema Compliance assertion will always be Valid. For example, this happens if you have defined the
This assertion is available in multiple ReadyAPI applications. Depending on the application, it validates the following data:
|In...||Checks...||To learn more...|
|SoapUI functional tests||The request or response body.||See Working With Assertions in SoapUI.|
|SoapUI security tests||The response body.||See Security Assertions.|
|ServiceV||The request body.||See Assertions in ServiceV.|
Specify the definition URL in the field.
By default, ReadyAPI uses the service definition that you specified in the project to verify the schema. If you have an inferred schema, ReadyAPI will use it instead.
For the REST Request test step, you can use only the inferred schema.
In SoapUI, if the response you receive has conflicts with a schema, the assertion fails. These conflicts appear on the Conflicts tab of the Schema panel in the response editor. You can then resolve conflicts on that tab – either manually or automatically.
For more information on schemas in ReadyAPI, see Inferring REST Schemas.
If you receive the
Missing matching representation for response with contentType error, add a new representation for the expected content type on the Representations panel:
Add other schema compliance assertions: