New Idea

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.

0 Kudos

Endpoint description/name

Status: New Idea
by martijn on ‎08-21-2017 03:50 AM

Since it is possible to configure multiple endpoints on a soapcall I think it would be a nice feature to  be able to assign a name or description to each endpoint. For instance, in a situation where you can only use IP adresses it would be nice to set the hostname in the description. Another usecase would be a 'production', 'test', 'accept' tag in the description etc.

 

0 Kudos

Hi,

 

Please resolve bug Null pointer exception with HTTP Monitor.

 

Http Monitor + create test case from selected request would be a very useful feature, but as far as I can see (in version 5.3.0) this is currently completely unusable.

 

Its working in Pro version, so I guess a fix wouldn't be very difficult to implement?

 

Kind Regards,

Paul Igoe

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

SoapUI Log scrolling

Status: New Idea
by hmanastasi ‎03-14-2017 12:01 PM - edited ‎03-14-2017 12:08 PM

It would be helpful if a user was able to choose whether or not they wish to have Logs scroll as they populate or not. Each log (Error, HTTP, Script, etc) should have their own setting and not have one setting to rule them all. I have created several scripted assertions with a great bit of detail. I have to wait until the test is finished running before I can describe or research the error I am receiving. This is not very efficient when I have individuals assisting with debugging of an application.

 

Heather A.

0 Kudos

Generate AWS REST API signitures

Status: New Idea
by ECiurleoIOP on ‎03-02-2017 01:34 AM

When making calls to Amazon's S3 and similar services a "signature" value needs to be generated.  

http://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html

 

The details of the signing required are documented here

http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html 

 

Currently this can only be accomplished with a convoluted mechanism of groovy scripts.  It would be very useful if (upon entering the relevant credentials) SoapUI could generate the signature value and populate the relevant header.

 

Displaying Groovy script test step result

Status: New Idea
by on ‎02-14-2017 04:31 AM

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:

GS-AssertFalse.jpg

However if the script is:

 

assert true

The icon remains blue, i.e. the same as before step execution:

GS-AssertTrue.jpg

It is a small change but it would help to recognize the test result.

 

Karel

 

0 Kudos

The navigation tree for SOAP services/requests was sorted alfabetically by name.

When one has many requests below the same Project it is possible to manually group them by adding prefixes in the description and hence keeping then "organised".

 

In the navigation tree for JSON on the other side  there seem to be a fixed sorting by creation time: the last created/or duplicated request is put at the end of the list.

When there are many requests it bekomes a caotic list.

 

It would have been better to keep the functionality of the navigation and editor pane (e.g. editable, searchable) like it was for SOAP and just treat JSON content as an other type of content.

 

I hope there is a chance to geht this right and more confortable in a next release.

Anybody else with the same experience using SOAPUI for JSON? 

 

0 Kudos

SoapUI command line Mock Deployment

Status: New Idea
by samuel_perez on ‎02-06-2017 11:14 AM

Description:

Need the ability to deploy the mock via a command line vs the UI.

 

Business need: the ability to integrate the Mock test cases along with Continuous Integration automated test.  As part of CI build need the ability to deploy the SoapUI Mock upon check in.  Once checked in the mock can be packaged as a war and then deployed to a Apache or TC container for use with automated regression suite.

 

 

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.

 

 

You may want to provide a corresponding hint in the check-box's text (or at least its hover-text), because that's not exactly intuitive. Without the reg-exp checkbox being ticket one needs to provide a substring only that has to be contained somewhere in the response. With the check box ticked, it needs to match the entire response.

 

Please make that difference more explicit!

 

Background here:

Re: Contains assertion with option "Use Token as regular expression" not working

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

 

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

The same feature would be nice for REST.

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.

 

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.

 

 

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.

 

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

Security Scans for REST -JSON

Status: New Idea
by Priya85 on ‎12-16-2016 01:29 AM

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.

AUTO RESOLVE SCHEMA CHANGES AT PROJECT LEVEL

Status: New Idea
by cnanju on ‎12-14-2016 02:46 AM

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.

Adding Groovy Grape dependency management out-of-the-box

Status: New Idea
by ‎11-07-2016 09:28 AM - edited ‎11-07-2016 09:29 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