Autogenerate test scripts from openAPI specs
is there a way to auto-generate test cases/scripts in ready API from openAPI specs - such the generated test scripts include contract tests/variation tests around the defined API attributes/supported data types and range of values for the APIs?
Solved! Go to Solution.
I cant double check as my laptop has crashed and i need to reinstall the operating system, however the short answer im gonn go with is "no".
At most creating a project from an openAPI definition will have the equivalent of the options if you create from a .wsdl....i.e. it might be able to create an example testsuite with testcases with example requests based on whats defined in the openAPI....i.e the requests' payloads will be examples too (based on openAPI definition), but the content wont be further tailored than that.
E.g. there wont be any cross field validation covered off, the fields in the payloads wont cover all the possible boundary analysis or equivalence partition tests and the fields in the payloads wont include minlength and maxlength test permutations.
Youll still need to do the typical test analysis you always do to build your tests to cover off all your acceptance criteria/verification points and if it did, it'd mean most testers would be out of a job!
Tbh, even when testing SOAP and importing a .wsdl, ive never bothered using the sample generator more than once to see how it worked, as my analysis drives how i build my tests anyway.
Hope this helped,
Not sure of your use case behind the question.
- The default generated test case be used to quickly check if all the endpoints are enabled or not like smoke test.
- Beyond that, lot of cases have to be added for the test coverage which have to be taken care by engineers and it will be time taking as well if it needs to be fully automated.
- Even scripting might be needed in order to achieve the same such as pass data from one response to next request's input etc.,
- One important thing to note is that the generated tests will not have any kind of assertions which is critical to say if the test is passed.
That's why (automation) engineers are on job, not just tools.