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
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:
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
Status:
New Idea
Submitted on
05-07-2015
06:12 AM
Submitted by
automatoramit
on
05-07-2015
06:12 AM
There should be Collapse All and Expand All functionality for Interfaces, Resources, Methods, Test Suites, Test Cases, etc. If user clicks "Expand All" in the top node of the tree, all levels should get opened. The same goes for 'Collapse All'.
... 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
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
SoapUI gives a window for each opened entity (testcase, teststep, request, etc.) and this is good. Only if you have more than 10 windows open, it is really annoying to switch between windows and find the window you want. Instead, it could work with a tab view (one window with a tab for every open window): at the top of the window, a title for each tab (previously: each window) and the option to close this tab (a small cross button). No maximize or minimize buttons, maximized as standard view of the window. Working with tabs is much more organized than lots of windows which you can't get an overview of. By dragging a tab outside the top line with tabs, the tab is moved to a smaller window without tabs (the window-view currently in production).
... View more
I have a degenerative eye disability caused by Usher Syndrome which is now turning impossible to work with dark text on white background. Whilst I use a Mircrosoft Windows accessibility feature called High Contrast it doesn't change SoapUI. If Smartbear can't create its own dark-mode for SoapUI, at least, could let Windows turn it to high contrast. Any help, be it any of the 2 features requested or a suggestion, is much welcome.
... View more
Status:
Implemented
Submitted on
02-01-2017
02:08 AM
Submitted by
KarelHusa
on
02-01-2017
02:08 AM
Configuration to allow loading unsigned plugins Description Currently SoapUI-5.3.0 allows to load only the plugins which are signed by Smartbear, for security reasons. This precaution prevents to develop, test and use the plugins which are not signed by Smartbear. Asking Smartbear to sign every JAR we need to test is not feasible. The enforcement of signing the plugins is contrary to open source principles. Proposal Introduce a configuration item in SoapUI properties, which allows loading unsigned plugins. The item can be set to false by default, but the user will be able to allow it at his own risk. There can be a short notice about potential risks. Benefits The implementation would allow more freedom and flexibility to both SoapUI contributors and users and encourage people to develop new/custom plugins.
... View more
Right now the only grouping possible is by project, it would be nice to be able to have folders inside this projects. This way the "workbench" can be a little cleaner. Anyway, thanks in advance and thanks for such a helping tool. Best regards and keep up the wood work! Federico.
... View more
It would be very convenient to work with several windows if they were organized as tabs, as in modern browsers. Now, to quickly switch between windows, you have to reduce their size and change the position of each other so that one window looks out from under the other. See attached screenshot.
... View more
Purpose When the Groovy Script test step fails, its star icon turns red and I can see the step has failed. When the step succeeds, the icon is still blue, i.e. has the same color as before its execution. Can you please make it green in case of test step success, as is e.g. in case of SOAP Request test step? Description When I run a Groovy script test step with a script: assert false The icon gets red: However if the script is: assert true The icon remains blue, i.e. the same as before step execution: It is a small change but it would help to recognize the test result. Karel
... View more
Find/Replace is available for SOAP request bodies and responses. The same feature would be nice for REST.
... View more
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
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
I worked many years with SOAP UI for SOAP/XML . Useful was the feature that the REsponse windows is actually an editor window where I could directly modify the response text (insert new lines, ) search for keywords,..etc... Now we are moving to JSON and the Reponse window for JSON doesn't allow editing, neither CTRL+F (Find) The only operation that seem work ist CTRL+A and then CTRL+C for copy. Hence a separate editor is needed... I am using SOAPUI 5.2.1 It shouldn't be a big change to allow editing in that windows as well, since you already allow editin in the SOAP response window. Most probably some detail in the configuration of the windows object for editor window called. OR the problem is that that window doesn't get the focus when pointed & click by the mouse. Hence the CTRL etc are sent to the neavigation pane. It would be good to have this fixed in a next release. Thank you! Adrian
... 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
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
