Would be helpful & efficient if there was a simpler way to compare datasources, especially when working with large data sets where multiple calls to db/json wouldnt be practical.
Scenario - Taking the results of a jdbc query & putting it into a datasource file. Then taking the results of a json query & putting that into a datasource file. Now compare the 2 datasource files to make sure the values match.
Can we, and if so how, use something like intellisense on a custom groovy library?
So if we have created some utility functions and keep them in a script folder, or library, can we then reference those scripts and their methods intelligently from a groovy test step?
AFAIK for SoapUI versions up to 1.8.0, the calltestcase step only supports calling test cases within the same project.
We have hundreds of utility test cases in a large project with ~1000 application level test cases that use them. We also have another project containing tests that need to call the same utility test cases. Currently we have to maintain two copies of the utility test cases because the second project cannot call into the first.
Instead, we would like to have one SoapUI project containing the utility test cases, and multiple other projects containing the application level test cases that call into the utility tests. Then we would not need multiple copies of the utility test cases, which is a maintenance headache.
So we'd like to request a SoapUI enhancement to support calling test cases in other projects. That would reduce our maintenance efforts considerably.
It will be nice to have the option to set generic assertion for all the API request in the project , or to select some of the APEs should have the same assertion .
meaning of generic assertion - The user will create the assertion and will have the option to set it the over API requests.
Motivation - I have hundreds of API requests, more then have of them have the same assertion ,so i need to copy paste them one by one.
Requesting for an enhancement to repeat the every HTTP/REST request for n times with specified delay between each trials until it passes its assertions.
We are facing a problem in our testing while using two web interfaces. The first REST send a request to second HTTP/REST service which will take some time (Not sure, it may be from 60secs to 300secs anywhere). With a hard coded delay, it was very tough and wasting lot of time for testing.
With this feature, it saves lot of time and effort. I knew this can be done through conditional step, but it has so much work involved with each step.
BTW, basic behavior of any HTT/REST request should not change by default. it should behave like as usual now. One more this is, it is test step level feature.
Test cases have options assigned to them, which define if the test should abort as soon as a step is on error; if the HTTP session should be maintained; etc. Those options can be found here: http://readyapi.smartbear.com/structure/cases/opti
As a developer who writes a lot of tests, I'd like to be able to define the default value of those options once so I don't have to edit each newly created TC.
For example almost all my test cases needs to have the "abort test is an error occurs" option disabled. Having to edit this option manually each time is pretty cumbersome, and easy to forget.
Hi within the virtserver (from within ServiceV) when you right click on a virt you have the option to 'Download' in doing so creates a new local project
can we have an option to disable this please
We have our project files under source control and we've inadvertently seen old versions of a virt deployed because somebody kept downloading the version from the virtserver as opposed to getting the latest from source control (which was work in progress and hadnt been deployed)
whilst I admit this isn't a technical issue and more of procedural education issue, this would be a nice to have to discourage people from potentially doing something detrimental and causing confusion
ReadyAPI ServiceV right hand window viewing/editing pane has a number of script nodes that have a script editing area that is not able to be resized vertically. Only 5 lines of script are visible when it should be able to grow as desired. Start Script, Stop Script, OnRequest Script and AfterRequest Script cannot be grown more that 5 lines. That takes a while to scroll through when those scripts are many lines long.
I had entered a ticket and got reffered to the community board for this enhancement request. I've notice since the release of Ready_API 1.4 several GUI memory related issues. Mostly because the current project that I an on required sucha large list on parameters, approximately 150. This has proven to be problematic when creating a datasource with a long list or a simalarly large number of assertions.
Having said that, the paarticular issue is as follows. I created approx. 150 test assertion, most of them were simple Match Content, comparing the Datasource Feed, with the output of a JDBC test step. I did this assuming thatthere would always be data, or particulatly formated data coming from the file feeding the datasource. Well when I had a difference from what I was expecting aI had an "Oh S@#$T" moment. Now I have to delete 150 assertions and recreate 150 script assertions.
Proposal: Enable the Assertion's "Expected Result" window to accept multiple expect data using logical AND/OR (&&/||) statements (See attachment). I know that there is a similar feature using th eAssertion test step, but its too bulky and wouldn't be worth the effort vs replacing with a script assertion. It also heps the script to me a bit more maintainable as future releases present similar siuations.
If I walk up to a workstation that has Ready!API up, I can't readily tell if a test package, suite, case, or step is in the middle of running, let alone which one is running. If something is executing, it should be glaringly obvious on the screen no matter which other item somebody has selected to look at, and it should be easy to tell what is running, and where it is in its sequence.
I'm using Ready!API 1.8.0
Can we get a mechanism to auto start virts when a VirtServer starts up,
if you're using a Large VirtServer at capacity the task of manually starting each applicable virt in turn is going to be somewhat tedious
a setting within ServiceV alongside or in the general Virt 'Info' section with a checkbox for 'Auto start with VirtServer'
then if the flag is set and the virt is deployed if VirtServer is stopped and restarted (sys reboot for example) the Virt would not need human intervention to restart it
an overall view would also be highly beneficial especially if it could also configure the flag whilst deployed
within the VirtServer panel in ServiceV where we can view the active Virts and Metrics etc, a view of all deployed virts and their auto start flags with the ability to switch on/off the flags (in a similar way the rows of data in a datasource can be switched on or off)
The routing option is too limited to be useable today.
At my current client we need the option to route certrain ranges to the real back end services, or the option to do so via scripting (return route instead of return template).
We have specific ranges of easily identifiable Virtual Customers, those should return one of our templates while real customers should return the real service response.
Right now, JUNIT reports are not modifiable at all. They are important when comes to running test cases via some CI and host result/report at a url. JUNIT reports are so simple and do not give information about the REQEST/RESPONSE of a failed step to actually look at the reason why the test cases failed on the test server which might run successfully on local. Across various communities, I see that this feature is required by most of the users, a lot of discussion around it, and the way suggested is via maven project which seems to put more effort than writing test cases.
Within ServiceV and the VirtServer visible (with running virts that have transactional history available)
view Transaction Log
drop down list of available of virts allows selection of applicable virts,
there is an icon next to the drop down that doesn't do anything but looks like it should be used to refresh the list
at present the list of transactions is auto refreshed, when you have to scroll down the list of transactions its a tad annoying to be bounced back to the top on every refresh, being able to disable the auto refresh would hopefully stop this behavior and allow uninterrupted browsing of the transactions list
also the list is currently ordered by oldest at the top down to newest at the bottom, being able to flip this ordering would be a nice to have
for Ref using
Build Date: 20160413-1835
In SoapUI 4.x, the navigation pane used to rememer it's last saved width between sessions. However, Ready! API does not remember this type of sizing information--every time you restart the app, the pans are back to their default sizes.
Please enhance Ready! API so that all of the panes and view windows remember their last sizes. Everything is resizable, but it's a waste of time to have to keep manually re-sizing things because the application doesn't remember the settings.
We specify our JSON-Format-Definition with the JSON-Schema.
It would be nice to validate the data directly within SOAP-UI.
Schema specification (IETF RFC Draft)
Using JUnit Tests rest-assured:
Please make the left navigation panes remember their hidden/visible status between sessions. Most applications remember these types of settings, and it is a shortcoming in Ready! API.
This should include settings for all items in the View menu. Currently, none of them remember their settings between sessions.
It's more user friendly to have these panes remember this settings. Otherwise, if someone wants View settings that are different from the default, they have to manually re-set them after ever restart of Ready! API. (e.g. The new API Navigation pane--since it uses a lot of space and causes issues with pushing the Properties pane off the screen, so I have to repeatedly manually hide it now).
Refering to forum post for the background: http://community.smartbear.com/t5/SoapUI-NG/Suppre
It would be nice with an option to determine what should happen when you update the definition of a service using a new WSDL location using groovy (WsdlInterface.updateDefintion()).
As it stands if the endpoint is changed the user is prompted with a yes/no question if he/she wants to update requests with the new endpoint, so a simple bool to the updateDefinition method would be awesome.