Call Json schema complaince assertion in groovy script assertion

[patilawaken]

I need to validate json schema only when there is 200 status code for the API. Can we have a script assetion created from which different assertions are called depends on the status code condition.

[richie]

Hi,


From your description it appears you just need to assert against different status code conditions. You don't need groovy for this. The OTB functionality already does this!

Cheers,

Richie

[richie]

Hi @patilawaken 

there is a page that in the soapui.org help that includes some code to assert against an xml schema (the .xsd) - you can likely tailor this to do your json schema validation, but before you start looking at that, I have a question.

What's the reason you want to add a schema validation in your tests?  The reason I ask is that be definition - if your request is validated (which it is if you have a .json schema) each time you publish to the web service the request is validated, so it's kindof moot that you'd add extra hassle by adding this in groovy script assertion to test this in your testing when you can do the schema valid/invalid testing without the hassle.

What I mean is - you are going to tailor requests that are both valid and a number of negative tests to ensure the invalid requests are handled correctly - right?  With this in mind - I don't know why you don't setup your requests (both positive (schema valid) and negative (schema invalid)) - then say create 2 separate looping tests (1 positive (schema valid) returning a 204 or whatever is the expected response and 1 negative (schema invalid) returning a 401 or whatever is the expected response).<-- this would satisfy your schema testing without having to add in a script assertion to do this

If you execute these tests you'll assert that only the valid ones return a 204 and the invalid ones return 401 or whatever.  This doesn't require script assertions at all - the OTB/embedded functionality will handle alll this using either the 'Valid HTTP Status Codes' and the 'Invalid HTTP Status Codes' assertions or just the 'Valid HTTP Status Codes' assertion.

To be honest - I've always struggled with the purpose of using schema validation in my tests as unless the validator isn't present in the environment you are publishing to (which it nearly always is), there doesn't appear to be any additional value adding in the code to actually do schema validation assertions to validate against a schema as all your requests are being validated before being consumed by the webservice anyway and you can do your testing without going through that headache.

I'm not saying schema validation checks aren't useful - but there's easier ways to do this testing without bothering adding in the schema validation groovy to do this - that's all.

Just an opinion.... 😉

Cheers,

richie

[patilawaken]

Hi @richie,
I am validating JSON schema of response to make sure response has all keys present by making all properties as required, also I can validate further to check the values have correct data types, formats, range and size etc, using single assertion I can assert many things in response.
Now since I am using data driven test where I am setting request body or parameters from data source, I have valid and invalid combinations in the loop.
When I get 200 status code it should validate the JSON schema
When it has 400 status code message should be specific, or may be multiple.
That's the reason I need to have status code assertions,
One way is to have conditional go-to to the assertion test step when response code is 200 and so on, or writing script assertion.

[nmrao]

Not done this kind.

But you can try below approach, but it needs to be coded.

a. Have a script assertion
b. Extract status from the headers
c. Have a switch construct and do the validation/assertions based on that.


Another approach is (may be crude), define all the required assertions.
Use Events feature, SubmitListerner.afterSubmit method, disable the assertions which are not needed based on the status code.
This way it is not required to write the code for ourself all required assertions.
Not to forget to enable all the assertions back once the test is complete.