Showing ideas with status Implemented.
Show all ideas
Status:
Implemented
Submitted on
06-14-2018
07:02 AM
Submitted by
gibsonman507
on
06-14-2018
07:02 AM
When cloning multiple test steps, there is no dialog to name each of the cloned test cases. ReadyAPI prepends "Copy of <teststep>" and this it becomes very tedious to rename each test step. I understand the purpose of prepending Copy of is so there's no duplicates within the same test case. My only request is that if the target test case for the cloned steps is different (therefore no need to make a unique identifier), that they simply clone as-is. IF there happens to be a test step with a conflict name in the target test case then it should be ok to auto prepend "Copy of". This would save lots of time when I clone 25 or so steps
... View more
Different projects may require the same environments. It would be useful to clone them directly rather than recreating them all over again.
... View more
Status:
Implemented
Submitted on
11-28-2017
04:25 AM
Submitted by
bwennekes
on
11-28-2017
04:25 AM
To extend the composite project functionality and improve the way ReadyAPI’s XML-files can be version controlled I would like an option to save without property values. Ideally this option can be enabled/disabled for properties defined at Test Step, -Case, -Suite and -Project level with a checkbox. Currently there is only the option to ‘discard values on save’, which is only available on Test Step level. Discarding values on save can be quite cumbersome if you need the values making changes/corrections while still wanting to save often. This could mean that you need to rerun the whole project after a change is saved, which in my case may take more than half an hour. At this time I’m still using the ‘discard values on save’ option by lack of alternatives. This also means that all properties in the project must be defined at step level, the only place where this option is available. This in turn means we cannot use functionality like the ‘Run Test Case’ Test Step as this uses properties on Test Case level, which is a real shame. In my opinion just running and saving the ReadyAPI project should not change the project XML. As this currently does happen it creates hundreds of changes and merge conflicts without any functional changes in the ReadyAPI project.
... View more
I work from a laptop with 2 extra screens and am having issues with Ready showing (up) correctly. - Ready on the main screens works correct - Ready on a second screen makes menus/dropdowns appear on the main screen (most annoying) - Sometimes at start Ready will not show because it is somewhere out of bounds of every screen. Can only be fixed by force closing the app, disconnect the external monitors and start Ready again and reconnect the screens
... View more
Hi. I have some eye issues and normally work with a dark background / high contrast in all apps. I use SoapUI daily and find it difficult to read with the default white background. I did a search on the forum and there was a previous request about a year ago in the SoapUI Pro area for this feature. The only response was that it was not supported. I would like to also request this feature. Thanks!
... View more
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?
... View more
Status:
Implemented
Submitted on
02-18-2021
11:00 AM
Submitted by
khanchett
on
02-18-2021
11:00 AM
Prior to this release test step assertions were always allowed to minimize, now it is not. I have groovy scripts and SOAP Request/Response xml that can be 100's or 10,000's of lines. * When my SOAP test step first opens up there is only 10 lines at a time that can display. * When I minimize the Assertion area I can get it to 15. Suggestions: * To collapse it on the right side so we can obtain the length of the screen. * Return it to allow the Assertions to collapse out of the way. Related suggestions: * For those of us that utilize ReadyAPI with Groovy and JDBC's more, it would be good to have better work area real estate when you push out these changes. * Also if a portrait screen was more user friendly I would use that more, unfortunately my home version (thanks to Covid) my portable monitor doesn't allow good screen resolutions. * Collapsing the left side and the bottom would be a fantastic option. Thank you!
... View more
With the release of ReadyApi 2.0 GetData behavior was changed and we are NOT impressed. Font size is set and unchangeable Column width is set and unchangeable This means that ANY TestSuite, TestCase etc. with names longer than 16 characters all look a like, making it impossible to be efficient as new functionality forces us to MouseOver to be able to find the correct TestCase name. Please at least make the GetData Columns resiazeable, so we can see the names of our TestSuites and TestCases again! See attached file.
... View more
Current Change:
In ReadyAPI 2.5.0, the soap and rest request run button, and for test steps Add Assertion button were tweaked to make them more prominent (they now include text labels). This itself is fine.
However, as part of this change the position of the buttons was also moved. They're now on the right-side of the destination URI instead of the left side.
Request:
Please put the buttons back to the left-hand side of the URI.
Reasoning for it's usefulness:
1. It's inconsistent design. The run button was ONLY moved to the right side for request test steps and operations. However, test cases, test suites, and JDBC test steps all still have the play button on the left-hand side. This breaks the consistency of the run button placement--people will now sometimes have to go to the left to run, and sometimes go to the right, all depending on what's being run.
2. Long-term users are also extremely used to the run button being on the left side, so it's a nuisance to have to keep moving over to the right side now to use it, when we habbitually go to the left-hand side first.
3. There was no need to move the buttons to the right--it didn't help increase the visibility of the buttons, and it doesn't provide any new benefits.
4. It also breaks certain usage patterns where I sometimes open a test request on a left pane, then one or two other validiton checks to the right of that, and they hit the run buttons from left to right while I'm trouble-shooting something. This works nicely when all buttons are placed on the left-hand side of their tabs.
... View more
Our organization would benefit greatly from integration with Allure Reporting. It would be great if SoapUi could allow for annotations, steps and links to be added directly in test case requests/steps that would then output the appropriate xml that generates the beautiful and detailed allure reports.
http://allure.qatools.ru/
... View more
Testrunner.sh currently supports the -T option, which allows users to specify which tagged test cases they want to run. However, there is not a flag that allows the user to specify which tags to ignore in your test run. For example, if I tagged test cases with "prototype" I could run only those tests with that specific tag using -T"TestCase prototype". However, if I wanted to run all tests but exclude the prototype tags I currently don't have the ability to do that. Maybe a new tag, or addition of ! into the flag would work? Ex: -T"TestCase !prototype" <----- where ! prefix specifies not to run tests with prototype flag This could even be expanded further where the -T option would support both inclusive and exclusive tags. Ex: -T"TestCase prototype !ignorethese" <---- run all tests that have the prototype flag, but don't run those that have ignorethese flag
... View more
Status:
Implemented
Submitted on
03-07-2019
07:07 AM
Submitted by
marcus_kobel
on
03-07-2019
07:07 AM
I'm using ReadyAPI 2.5.0.
Please implement a feature where I can search for text pieces accross all test steps, regardless their types.
Right now I can do this by searching through the xml project files, but it's clearly not the best (or most friendly) option.
... View more
Any clone/move renames testcases/suites/steps to 'Copy of'. That is unnecessary if moved to a location, where no copies of them exists. Why not let me clone one or more teststeps, select a destination, and THEN check if one with the same name exists, and if it does, then let me decide on the name? It is especially annoying when cloning multiple objects, as you can't rename these before the cloning. And it gets even more annoying when you clone TestCases, as the new clone's file on the disk is then named 'Copy of'... ' and if you do not want mismatch between the TC name in ReadyAPi and on the disk (relevant when commiting to GitHub), you then have to manually rename the files on the disk afterwards.
... View more
Provide an option to also list the Test Steps within each Test Case in the JUnit report. Or provide a way to drill down on each Test Case if needed, by default it can still only show Test Case results. This will be greatly benefit for reporting under a Continuous Integration system.
... View more
Status:
Implemented
Submitted on
09-17-2015
10:59 PM
Submitted by
TNeuschwanger
on
09-17-2015
10:59 PM
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.
... View more
Status:
Implemented
Submitted on
12-28-2015
11:45 AM
Submitted by
sprice090161
on
12-28-2015
11:45 AM
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.
... View more
Status:
Implemented
Submitted on
03-06-2017
12:56 AM
Submitted by
goliontus
on
03-06-2017
12:56 AM
Hi I would like to suggest the development of a FTP/SFTP TestStep where I can FTP a generated DataSink file. That will assist me greatly in automating an entire end to end process without the need for Groovy. Thank you. Regards Charles
... View more
I want to disable large toolbar on TOP . I need to use small notebook for traveling. On 13" display it reduces space for working area. Case: 00101360
... View more
Status:
Implemented
Submitted on
08-25-2016
03:05 AM
Submitted by
Gurbakhsish
on
08-25-2016
03:05 AM
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.
... View more
See more ideas labeled with:
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/options/basic 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.
... View more