JuZ0
Contributor
Joined 2 years ago
User Profile
User Widgets
Contributions
Re: OpenAPI/Swagger 3.0 Support
They should. They have code but have intentionally left it out from Open source edition. In 5.7.0 release notes: Built-in OpenAPI (Swagger) support Now, to work with OpenAPI/Swagger definitions, you do not need to use plugins. SoapUI supports it out-of-the-box. Additionally, we've improved integrations with SwaggerHub to make it even more convenient. They should have included OpenAPI 3.x support in that change. I guess it could happen eventually when some other vendor Open source tools gain more weight. OpenAPI is kinda industry standard so it should be supported in regular basis and not seen as some premium feature. In the meanwhile I would suggest that community creates a plugin for OpenAPI import functionality.125Views1like0CommentsRe: SoapUi Groovy conditional property transfer
I would extract that value by utilizing Groovy XML slurper in Groovy script test step. When you return value in Groovy script test step, you can utilize this value in succeeding test steps and make logic based on whether return value is not empty. Property transfer test step could also be a viable option with XPATH but it can be more tedious with more complex xml.126Views1like1CommentRe: Adding a property variable in Access Token field returns invalid token.
Could you provide example project with possibly placeholder endpoints? That would make it easier to see the possible problem. Some thoughts: In first post you do mention that first token retrieval request is in testsuite1 and the second request that utilizes the token is in testsuite2 and that you are using property transfer to set token value to testsuite1 property. In my understanding it is not possible to retrieve testsuite1 property value through request2 in testsuite2 with property transfer. Property transfer can only retrieve testsuite properties that are in the testsuite where the property transfer step is belonging to. In this scenario you would have to transfer property to the project level and from there you would be able to get with property transfer that is running under testsuite2 because the project level is common between testsuite1 and testsuite2. However you may have already tried this if I interpret your another post correctly. You said you do get the 401 error while using property expansion in request2 authorization header. If you check the raw request that is sent, what do you see? Is the token header present and does it contain some value or is it empty? You mention "I even tried to put directly the token access in Value after Bearer, it returns 401 authentication problem". So the token is sent and the response is still 401? Have you gotten this same token work with postman or with another way in SoapUI? Could you compare succeeding raw http request to unsuccessfull raw http request to pinoint any possible differences?25Views0likes0CommentsRe: Adding a property variable in Access Token field returns invalid token.
Without some project example it is difficult for me to follow what is happening. In general for me bearer tokens and property transfers have been working fine in SoapUI. In my usage I fetch bearer token by using HTTP or REST test steps instead of using any built in mechanism in authorization tabs. With manual control you will know exactly what you are doing. When inputting bearer token to the request, you should use Header assignment by adding "Authorization" named header with value "Bearer <tokenPropertyValue>". This is in my experience most reliable way. Also remember to remove any built-in authorization options from the test steps,they may interfere "Authorization" header setting. In your case I would suggest adding Fiddler or some other proxy in between. From there you could inspect the actual HTTP request and its header values and compare it to the working case. This way you could pinpoint any differences.135Views1like0CommentsRe: Query regarding the SOAP UI open source and Java SE license
5.4.0 is quite old version. Here is some release history article: https://www.soapui.org/downloads/latest-release/release-history/ It says for 5.4.0 following: ”SoapUI now uses Java 1.8.”. SoapUI 5.6.0 has following mention: ”Support for openJDK 12” So the switch from Oracle Java 8 implementation to OpenJDK happened in 5.6.0 version on 2020. I think Oracle renewed its licensing politics after JDK 11 which lead many organizations to move to OpenJDK implementations.1.2KViews0likes0CommentsRe: Is it possible to split up your project.xml file into lost of smaller testsuite.xml files?
It is totally possible to code a separate tool that would split a single soapui project file to a multiple files structure for GIT. Also this tool would compose multiple files to a single SoapUI project file. This tool can be done in plain Java for example. SoapUI project XML is easy to split since interfaces and testsuites are in their own separate elements that can be gathered and outputted to separate files as is without any further processing. You would just handle the XML structure. You could go further down and even separate TestCases and TestSteps in separate files, but I would suggest starting from TestSuites. TestSuites already offer a good separation and if for some reason multiple people are working with same testsuite XML, conflicts are much easier to resolve compared to resolving conflicts within possibly large SoapUI project XML General structure of decomposed project stucture would be: - ProjectFolder - interfaces - orderfile.txt - interface1_<guid>.xml - interface2_<guid>.xml - testsuites - orderfile.txt - testsuite1_<guid>.xml - testsuite2_<guid>.xml - project_<guid>.xml The <guid> in the name is the "id" attribute available in SoapUI XML elements: - con:soapui-project - con:interface - con:testSuite orderfile.txt is a file that keeps track the order of the testsuites and interfaces in the project XML. In project XML the physical order of these elements tells in which order they are shown in the UI. There is no any separate order attribute that would do such a thing. That is why it could be good idea to use order file. In the order file you could for example include those <guid> identifiers in specific order. This would then allow tool to combine and put those elements in correct order when composing a single project file XML from multiple files. So basically this tool would go through SoapUI project XML and then split from the project XML each of following elements - con:interface - con:testSuite And put them to a separate file in folder structure accordingly.164Views0likes0Comments