Check Out the Latest News About SmartBear Connect
New Idea

Workspace support for scripting

Status: New Idea
by on ‎09-19-2016 04:18 AM

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.

 

0 Kudos

Expand Resources listbox - user friendly UI

Status: New Idea
by Asubbiah on ‎04-12-2016 09:34 AM

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.

 

 

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.

 

Compare test step

Status: New Idea
by on ‎01-16-2017 11:37 PM

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.

 

0 Kudos

TestStep PropertyEx​pansion

Status: New Idea
by xavjer on ‎11-05-2015 01:55 AM

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).

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.

 

Find/Replace is available for SOAP request bodies and responses.

The same feature would be nice for REST.

 

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-upperca...

Status: Implemented

This feature request has been implemented in version 5.3 (shown in Bug Fix section 'A bug fix by bearsoftware (GitHub nickname): The Request URL property of the HTTP Request test step did not allow capital letters. (SOAPUIOS-213)')

If you need to add two or more WSDLs from your file system, every file you add starts the "browse" dialog from SoapUI's instalation folder.

 

It would help a lot if the last path is remebered, so no need to navigate to the directory every time.

 

Thanks again.

 

Best regards,

    Federico.

Collapse All and Expand All Feature

Status: New Idea
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'. 

Status: New Idea

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

 

0 Kudos

Support HAWK Authentication

Status: New Idea
by pcheng on ‎10-22-2015 11:55 PM

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.

Search and replace

Status: New Idea
by PLandhage on ‎01-10-2017 10:50 PM

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.

0 Kudos

Hello,

 

I've been using the mock functionality and I have a feature request to make.

 

In Home / Documentation / SOAP Mocking / MockOperations and Responses:

 

https://www.soapui.org/soap-mocking/mockoperations-and-responses.html

 

Section MockOperation Dispatching:

  • SEQUENCE: this is the simplest dispatch method; responses are selected and returned in the order they have been added to the MockOperation.

 

If you are setting up a mock service with a bunch of fake responses and you need to change their order, it can become quite cumbersome since you would need to recreate them or swap their contents around.

 

I wish there was a better way to reorder the responses, preferable by dragging them, without having to use a QUERY-MATCH MockOperation dispatcher, which would involve more complexity.

 

cheers

0 Kudos

Hi All,

 

Is there any assertion in Soapui Pro, that can be used to assert the response XML partially using regex pattern.

 

For Eg : Lets assume the response XML is something like this below:

 

<root>

<a1>This is a1 test</a1>

<a2>adding a2 text</a2>

<a3>

<b1>Some random text</b1>

<c1>hello</c1>

</a3>

</root>

 

And i want to assert this xml partially using some regex. Lets say like this below:

 

Contains Assertion: 

<root>

<a1>This is a1 test</a1>

*.*

</a3>

</root>

 

-----------------------------------

 

When i actually try to do this, it's not working. Can some suggest me the actual regex pattern that can be applied on the above XML to assert its response body. (Note : I am making use of 'contains' assertion)

 

Kindly let me know, if this feature exists (if yes, plz suggest regex for above & if NO, can we add this feature in next release of soapui pro).

 

 

Thanks

Singh

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.

 

 

SoapUI - Folders in Projects

Status: New Idea
by peterhammer on ‎08-12-2015 07:21 AM

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.

0 Kudos

Run TestCase from an other project ...

Status: New Idea
by GerBluem on ‎08-13-2015 12:52 AM

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

Make Soap UI compatible with Selenium 3.X

Status: New Idea
by rich-peters ‎01-24-2017 05:34 PM - edited ‎01-24-2017 05:35 PM

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.