SoapUI Pro - OAS3 - Swagger Compliance Assertion does not respect the Nullable flag
I am currently evaluating SmartBear's toolset for suitability for my company - specifically SoapUI Pro for automated API testing of our large suite of APIs which are in described in OAS3 format - and I have hit on this issue.
When importing the following (example) OAS3 specification in SoapUI Pro:
openapi: "3.0.0" info: version: 1.0.0 title: Swagger Petstore license: name: MIT servers: - url: http://petstore.swagger.io/v1 paths: /pets: get: summary: List all pets operationId: listPets tags: - pets responses: '200': description: A paged array of pets content: application/json: schema: $ref: "#/components/schemas/Pets" components: schemas: Pet: required: - id - name properties: id: type: integer format: int64 name: type: string tag: nullable: true type: string Pets: type: array items: $ref: "#/components/schemas/Pet"
That uses the Schema Object "Nullable" field for the "tag" property of the pet model.
And creating a stub of the service in ServiceV the returns the following response on GET /pets (with "tag" set to null):
[ { "id" : 0, "name" : "string", "tag" : null } ]
When I run the tests against the stub I receive the following error from the Swagger Compliance Assertion:
instance type (null) does not match any allowed primitive type (allowed: ["string"]) checked node: [/0/tag] corresponding schema: [/items/properties/tag]
It seems like the swagger compliance check is not respecting the new OAS3 "nullable" field, as according to the spec "tag" is nullable so my response is valid.
My real services have a large number of nullable fields so I would need this to be working in order to adopt SoapUI as my preferred API testing solution.
Any help appreciated.
Version of ReadyAPI I am trialling:
ReadyAPI 2.6.0
Build Date: 2019-01-14T14:47:06Z(2261)
57460326ed5636e3c392e5981c683c817f5091d8
Here are some resources I looked at when investigating this issue:
* https://assertible.com/docs/guide/assertions#create-json-schema-assertions-for-openapi-v3-responses
* https://github.com/OAI/OpenAPI-Specification/issues/1368
PS If this is a bug should I raise it elsewhere?
Hello
I have re-tested this bug on ReadyAPI 2.8.0 and I can confirm it is fixed.
Thanks