Skip to content
This repository has been archived by the owner on Jan 11, 2019. It is now read-only.

Responses are not validated against swagger definition #54

Open
flounderpinto opened this issue Feb 15, 2017 · 5 comments
Open

Responses are not validated against swagger definition #54

flounderpinto opened this issue Feb 15, 2017 · 5 comments

Comments

@flounderpinto
Copy link

Responses are not properly validated against the provided swagger definition.

To reproduce, create a swagger definition with an 'integer' field. Create a response with a non-integer response. Validation will not fail. Additionally, invalid tags will also not cause a failure. Actually, I can't find a way to make the validation fail at all.

It appears (in ValidationSupport::validateMessage() ) that a JSON schema validation is being performed and not a swagger validation. By reading the warnings generated, the schema validation reports a warning on all swagger keywords ("swagger", "host", "schemes", etc...).

@olensmar
Copy link
Contributor

thanks - looking into it!

@flounderpinto
Copy link
Author

Sorry for the nag, but any update on this? We just really need this to work before moving forward with SoapUI.

@olensmar
Copy link
Contributor

hm... the code looks ok to me - can you share an example swagger and message payload that should fail (or not) ?

@olensmar
Copy link
Contributor

@flounder5 ping?

@garysole
Copy link

Old but was this ever fixed. Have the same issue. Looks like it only does a valid JSON, but does not confirm that the response matches the Swagger Specification. Specifically change the response to cause a fault. Did not fail. Was able to discover a fail based on an incorrect type (Integer vs Double). But it is not validating that the field name is correct. Currently doing trial of ReadyAPI - this is the highest priority capability we want in the product. Without this, ReadyAPI does not fit our needs.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants