-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TCK Proposal - @SchemaProperty #469
Labels
Comments
Azquelt
pushed a commit
to Azquelt/microprofile-open-api
that referenced
this issue
Mar 17, 2022
…-io-commons-io-2.8.0 Bump commons-io from 2.7 to 2.8.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: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 aNumberFormatException
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.
The text was updated successfully, but these errors were encountered: