When investigating/implementing negative test scenarios for @SchemaProperty with the SmallRye implementation of OpenAPI-2.0, I found inconsistencies between the expected and actual negative behaviour of this annotation's various attributes, when purposely trying to pass invalid values to each of @SchemaProperty's attributes.
For example, for tests involving the maximum attribute, the JavaDoc states the following behaviour should be observed:
Sets the maximum numeric value for a property. Value must be a valid number. Ignored if the value is an empty string or not a number.
By the JavaDoc, setting maximum to invalid values such as "", "some-alphanumeric-sequence", or "" + Float.NaN should then result in these values being ignored. Here, I believe ignored may mean omitting this field from the resulting document, or setting the value to some default valid value, though ignored is not defined in the JavaDoc. In practice, these values result in a NumberFormatException being thrown, which doesn't seem compliant with the JavaDoc.
Other attributes also display examples where invalid values are rendered on the resultant OpenAPI document without any issue as if they were valid. For example, pattern, with an empty string value. Yet the JavaDoc states these should be ignored.
Rather than implementing tests within vendor implementations, I believe it would be beneficial to the MP OpenAPI implementation to provide TCKs for behaviour such as this which is defined in the JavaDoc. This behaviour can then be standardised between MP OpenAPI implementations, resulting in vendor compliancy and consistency with the specification.
When investigating/implementing negative test scenarios for
@SchemaPropertywith the SmallRye implementation of OpenAPI-2.0, I found inconsistencies between the expected and actual negative behaviour of this annotation's various attributes, when purposely trying to pass invalid values to each of@SchemaProperty's attributes.For example, for tests involving the
maximumattribute, the JavaDoc states the following behaviour should be observed:By the JavaDoc, setting
maximumto invalid values such as"","some-alphanumeric-sequence", or"" + Float.NaNshould then result in these values being ignored. Here, I believe ignored may mean omitting this field from the resulting document, or setting the value to some default valid value, though ignored is not defined in the JavaDoc. In practice, these values result in aNumberFormatExceptionbeing thrown, which doesn't seem compliant with the JavaDoc.Other attributes also display examples where invalid values are rendered on the resultant OpenAPI document without any issue as if they were valid. For example,
pattern, with an empty string value. Yet the JavaDoc states these should be ignored.Rather than implementing tests within vendor implementations, I believe it would be beneficial to the MP OpenAPI implementation to provide TCKs for behaviour such as this which is defined in the JavaDoc. This behaviour can then be standardised between MP OpenAPI implementations, resulting in vendor compliancy and consistency with the specification.