Schema inference is definitely a good way to auto resolve schema conflicts if there are one or two test cases for which a schema change will affect. But if there are say some 600 test cases on a single Rest URI then it's pretty hard to go to each test case and then click on "Resolve all conflict".
So if we have this option at the menu/context menu level we can achieve auto schema resolve at all points(like Project level, Test Suite level, Test case level or Test Step level). Also a reverting option of what has been done would also be a great value add.
AUTO RESOLVE SCHEMA CHANGES AT PROJECT LEVEL
- rupert_andersonValued Contributor
Hi,
As a way to trial this functionality, I have created a custom SoapUI menu Action to allow changes to REST request content to be pushed out to all related REST TestSteps. Please take a look if you are interested, here are the links to the GitHub project and associated blog post:
https://github.com/bearsoftware/ReplaceRequestInAllTestStepsAction
http://rupertanderson.com/blog/replace-teststep-request-soapui-plugin/
I haven't tested it with a large project, but it seemed to work correctly in the sample projects I tried.
Please let me know any feedback / questions / suggestions.
Thanks,
Rupert
- cnanjuOccasional Contributor
Thanks Rupert, I am really excited to see such a quick turn around on the feature request. Will go through it and let you know ASAP. Once again thanks to your whole team for quickly releasing the feature.
- rupert_andersonValued Contributor
Hi,
Thanks, it will be great to get your feedback on it.
Just for the record, there is no 'whole team', just me as the developer, you and whoever else in the community that might be able to help! Hopefully thats all the team we'll ever need :-)
Regards,
Rupert
- kondasamyRegular Contributor
rupert_anderson: Excellent try it is; I have tested it in my SoapUI OS and it works fine. Here are my feedback thought to say,
- This could be extended to SOAP requests/ operations as well
- Currently actions.xml is not within the packaged JAR; it would be better if comes within the JAR (I hope this will be done in Phase 2 of your project goal)
- This plugin style follows legacy development approach, which could be improved with the new style of coding which makes to easily fit into the plugin manager of Ready API.
I also have some more extended idea to modify nodes of XML or JSON, which can be kept optional right now. I also wish to do a pull request and would like to contribute, if you don't have any concerns.
Thanks,
Kondasamy
- rupert_andersonValued Contributor
Hi kondasamy,
Thank you very much for your feedback, that is what I need, as it's really useful guidance and encourages me to develop the functionality further :-)
- SOAP version - I can do this, or you can maybe, let me know, good enhancement anyway.
- I deliberately did it the old fashioned way for the purposes of trialling the functionality - also for the reasons discussed here https://community.smartbear.com/t5/SoapUI-Feature-Requests/Configuration-to-allow-loading-unsigned-plugins/idi-p/135566 - basically the need to sign the plugin was putting me off, as KarelHusa described - however I am happy to provide alternative packaging as a plugin now that someone i.e. yourself, has shown an interest, would be neater like you say and was on my roadmap - Are you looking to use it with Ready API or both? I don't have that, so maybe you can help me test it there?
- In terms of pull requests - please go ahead! If you want to discuss anything please let me know, happy to chat!
Other ideas I had were:
- To also allow the media type to be replaced, along with the parameters.
Thanks for your help,
Rup
- kondasamyRegular Contributor
Yes I will do the pull request on your repository. I would be happy to help with testing and using it in both OS and Pro version. I like the media type changing idea as well.
Thanks,
Kondasamy
Related Content
- 2 years ago
- 2 years ago
- 2 years ago