Every time I launch SoapUI (5.3.0, but the same was in 5.2.1) I get an error: Thu Jan 26 18:42:52 CET 2017:INFO:Adding plugin from [C:\Users\Karel\.soapuios\plugins\soapui-swagger-plugin-2.2-dist.jar] Thu Jan 26 18:42:53 CET 2017:ERROR:An error occurred [com.eviware.soapui.plugins.auto.factories.AutoImportMethodFactory], see error log for details Can you please resolve this issue and advice a temporary workaround? The plugins actually work, but every time I launch SoapUI (either GUI or programatically) I get an error and need to check whether it's this known error or some other issue with my projects. The only advice I have seen to resolve this is to remove the .soapuios directory, which is actually a workaround, not a solution, as long as we want to use the plugins.
... View more
Soap UI 5.x versions are currently unusable from the last 2.x versions of selenium up to version 3.X. This is due to dependency mismatches in the http client which prevent inter-operability in the same JVM. Soap UI is a viable solutions for web testing with Selenium, we used it for many years in the past. Currently it is unusable. This is a very nice way to do web testing when it works, and many folks have asked about this.
... View more
Purpose The process of testing often requires to compare test results to expected values. When we need to check a specific value, we can use assertions. However, there are often occasions when we need to compare one documents to another (e.g. XML, JSON). I propose to introduce a new type of test step: Compare test step. Functionality Compare test step would allow: Select documents: users would select source and target document from test step requests, responses, properties and other document holders in SoapUI environment, similarly as the Property Transfer test step does. Type of comparisson: the user could choose whether the documents have to be identical (both structure and values) or similar (only the structure should be same). Also the user could choose to ignore differences in whitespaces, attributes, or namespaces, or even data types which to ignore (e.g. xsd:dateTime is typically different). List of items to compare/ignore: the user could list the items which should be ignored, represented by XPath statements. Also there would be an opposite option: a list of XPath statements to check and to ignore the rest of the documents. Suggestions The Compare test step can utilize the XMLUnit library for XML and thus expose its function via SoapUI user interface. The Compare step can be similarly used for JSON documents.
... View more
I a really miss a search and replace function. It should replace all test objects like testcases, testsuites, properties, request etc and also in groovy scripts and other test resources like description as well. It would be nice if you could have a replace all and a replace current (where you have to confirm each change). You can search and replace directly in the xml file but it is quite cumbersome.
... View more
Currently we have security scans available for SOAP protocol but we do not have the same for JSON. In NG PRO we have the JSON security checks. Can we also add them in the SOAP UI open source, this will be very helpful.
... View more
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.
... View more
Status:
New Idea
Submitted on
11-07-2016
09:28 AM
Submitted by
rupert_anderson
on
11-07-2016
09:28 AM
Hi,
Groovy Grape dependencies can be a nice alternative for adding Maven repository dependencies at runtime (as an example please see my blog article http://rupertanderson.com/blog/r2-soapui-groovy-grape-dependencies/). To enable Grape dependency management it is necessary to add the ivy jar to SoapUI's classpath (needs to go in the /lib folder, rather than the usual /bin/ext/), making it a bit less of a standard bolt-on.
It could be a nice improvement to add Ivy to the standard SoapUI distribution to enable Groovy Grape dependency management in Groovy TestSteps etc out-of-the-box.
I have tested including Ivy 2.4.0 as part of the current 5.2.2 source in GitHub and it appeared to work OK - not that I have everything of course.
If other people think this would be a nice feature, please vote for this request and I'll pick it up and submit the change for approval.
Thanks,
Rupert
... View more
See more ideas labeled with:
Support for development and execution of generic scripts I would appreciate additional support for scripting: - script console to develop and execute generic Groovy/Javascript scripts (similar to Groovy script test step editor) - list of custom scripts (either stored in a folder or in a workspace configuration xml), with the option to create, save and modify scripts The motivation: there are often situations when I need to execute a script which does not belong to any test, e.g.: - bulk change of a property within a project (or multiple projects) - launch several selected test suits - launch all test suits of selected projects - generate a test project from a list of WSDLs etc. Currently: the projects support scripting: setUp scripts, tearDown scripts, Groovy test steps, Groovy assertions etc. When I need to launch a generic script I have to use an existing project, create a Groovy test step, do the scripting, then do the cleanup. Some other users create a new test project just to develop and debug scripts, then delete it. This is ineffective. If I launch the tests from command line, I cannot use the SoapUI user environment to analyze the test results. The scripting support would provide both -- the efficiency of scripting and the comfort of the user environment.
... View more
Status:
New Idea
Submitted on
08-12-2016
01:41 AM
Submitted by
BhuvanShanmugam
on
08-12-2016
01:41 AM
It would be great to have facility to clone assertions to multiple TestCases in one go. Current support is to target only one test case in a test suite. The same idea can be extended to choose multiple target TestSuites and in each Suite select all/specific TestCases to copy assertions to. Thanks for considering.
... View more
I have multiple resources (say 25) under a rest service and I have to select few (say 15) services to generate testsuite. But the Generate Testsuite window expands with white space. The resources list box cannot be expanded for me to view/select the service easily. It is very hard to scroll after selecting 3 services. PFA the screen shot for reference.
... View more
The responsiveness of a system under test may vary widely depending on the environment. Tests that worked in one run may fail in the next run if the system took longer than expected to respond, then pass again in another run. Such variable responsiveness may be acceptable, depending on product requirements. Idea: Enhance restrequest steps to support retries. Let the test developer specify the max # attempts as well as the delay between attempts (e.g. millisecond). Enhance logging to record the #attempts required until test completion (e.g. test step completed after 3 attempts and 3984 milliseconds delay) or similar. Set default max #attempts=1, with default delay blank or some value that is grayed out when max #attempts=1. Enable setting of the delay when the user sets max #attempts > 1. Benefits: provide some resilience to functional tests so they continue to succed (from a functional perspective) even when system responsiveness varies provide logging information that lets other tools track the evolution of system responsiveness allows tests to simulate how real components in a loosely-coupled system would interact with each other (i.e. with retries) Other thoughts The "number of retries" can be confused with the "number of attempts", the latter being one more than the former. So the name for such a capability would have to be chosen and documented carefully. Creating a separate step type would avoid modifying the existing restrequest type (less change to existing step). However the existing restrequest type could be enhanced in a backwards compatible way and avoids having to explain when to use the old restrequest step and when to use the new one (more transparent).
... View more
This file is missing in the SmartBear maven repository http://smartbearsoftware.com/repository/maven2/com/smartbear/soapui/soapui-project/5.2.1/soapui-project-5.2.1.pom It is referenced from http://smartbearsoftware.com/repository/maven2/com/smartbear/soapui/soapui/5.2.1/soapui-5.2.1.pom
... View more
Let's say I make a call to a rest api and the response is json. When the SOAPUI REST call has completed, it will still default to XML as the default response type (assumedly because SoapUI is very XML centric due to it's Soap connection). You should spy the resulting content using response header or content. Or maybe it is not working because my particular content-type is using charset=UTF-8. Content-Type application/json;charset=UTF-8
... View more
As suggested creating a 'New Idea' of my forum post 1. TestStep expansion It is currently possible to use this property expansion ${#TestCase#MyTestCaseValue} but this one is not possible yet: ${#TestStep#MyCurrentTestStepValue} 2. TestStep expansion by name change Let's assume my TestStep is called: Step1 It has a parameter with name: Value1 So to access it, I currently use: ${#Step1#Value1} Now, when renaming a teststep or cloning it (and giving it a new name), all existing property expansions should also be renamed to reference the new name (In HTTP TestStep for example it should check the endpointURL, the content, the assertions).
... View more
Hawk is a relatively new technology, crafted by one of the original OAuth specification authors, that intends to replace the 2-legged OAuth authentication scheme using a simpler approach. It is an authentication scheme for HTTP, built around HMAC digests of requests and responses. I recent SOAPUI build, this type authentication is not supported. It would be nice if we can support this.
... View more
In custom properties at project level I observed that when I provide the value for the Password as a variable, it shows as hidden (****) However when I run the request using the variable I could clearly see the password value in the RAW Request. This sometimes makes me feel hesitant when I am wrapping the project and sending it to someone else to run it or creating regression which everyone can see. I expect that if user intetionally pick to encrypt or hide the password, it should not be visible anywhere. Not even from the raw request. Let me know what you think or if there is any better way to hide it.
... View more
In Soap UI it would be better if we have Pause and resume options while executing the Test Suite during the run time, so that it would better for debugging purposes. Currenlty we have to cancel the test execute and do the necessary debugging if some thing fails and again we need to execute the test suite from the beginning.
... View more
The load test feature in Soapui is great and simple. Jmeter has one key feature - to be able to replay an access log from apache and turn it into a load test. Can soapUI do that?
... View more
In soapUI 5.2.2 I have to use a property or modify the xml file directly to be able to test against a URL with mixed case it should just be allowed. Refer to Question on How for the the workaround i want to avoid http://community.smartbear.com/t5/SoapUI-Open-Source/How-do-I-create-a-HTTP-Request-URL-with-uppercase-characters/td-p/105180
... View more
There should be the possibility to run testcases from testsuites of foreign projects. Cool sideeffect will be that project files could be smal and straightforward and could be separarted for a single service (wsdl) of distributed software environment. The maintenance effort could also be reduced to a minimum, when WSDL/API of one service changed it's just necessary to update the main testcase and all linked 'run testcases' were automatically updated. kind regards, Gerhard
... View more