ReadyAPI Feature Requests

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

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

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

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

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

  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. ... View more

Enhancement Request: It would be useful if we add an extra "Suite Group", or "Suite Categories" level in the SoapUI test case hierarchy for organizing test suites. This would be a parent of Test Suite. This way you could collapse.expand categories of test suites. This should be an optional level, so that those who just want test suites wouldn't need to have the extra layer of categories.   Reasoning for it's usefulness: Currently, in each project, we organize tests by test suite, and test case. There is no broader category than test suite.  In a situation where you have multiple APIs that while might mostly be independent, but that do also have interaction with each other, it would be handy to have them all be in a single project.   However, if each API itself needs several test suites for testing it, then having multiple APIs in a single project isn't great for organizing your test suites, since they're all in a flat structure at the test suite level.  That's one reason for keeping the APIs in different projects, so that you can expand only the test suites for the given API, without seeing a bit list of all the other API's test suites.   The most common usage for Suite Groups/Categories would likely be to organize test suites by each API in the project, but their would certainly be other categories that people would come up with. ... 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

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. ... View more

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

Reference Issue - https://community.smartbear.com/t5/ReadyAPI-Questions/Ready-API-3-42-0-automatically-updates-projectVersion-every-time/m-p/240988/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExBSklETVhHWkdEMTUxfDI0MDk4OHxTVUJTQ1JJUFRJT05TfGhL#M57307   projectVersion value changes everytime a project is saved. When trying to Pull changes from git, setting.xml needs to be committed first, but it re-appears again as a new change, which blocks pulling from git.  The "Discard all changes", don't really discard the document. ... View more

Hi, it would be nice if Data Sources can be used for the whole project. Right now it is limited to the test case level. ... View more

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. ... View more

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. ... View more

Smart Assertions are very useful when having lots of data that need to be asserted.  However currently there are a few issues that make it more difficult then it needs to be:    1. No Search Facility that allows quickly to jump to an item.  2. No conditional flow where assertions can be managed depending on some response details. 3. No facility to deal with lists that are unsorted and can be in a different order each time. 4. No facility to convert the Smart Assertions to Groovy Script which would make it useful as a tool to get a basic script with all the assertions that can be further edited to deal with special cases.   Our responses contain hundreds of pieces of data that need to be evaluated. The Smart Assertions are great for quickly generating the assertions of a response but since we have many lists which don't arrive in a specific order, this does not work very well for us.  If the Smart Assertions could recognise lists and pre-order them before assertion this would solve this problem and save us a lot of time.     We also have an issue with repeated properties like for example version numbers that we only want to change once and then have it used in many places.  However using a property only works as long as the data doesn't change.  When data changes and we have to make a "Load from Transaction" again, those properties have to be added again.  It would be nice to have something like an "Update from Transaction" that notices changes but doesn't overwrite existing items that haven't changed and preserves the properties being used.  A differential dialog might be useful here when updating where we can see the changes, modify them if necessary or have them applied.   Another great feature would be a conversion from Smart Asserts to Script.  Other test applications that we use for desktop applications already can do this and it would be nice if SmartAPI also would be able to generate a script from the Assertions.  This would help with situations where we need to have lots of special flows , loops and transformations of data but don't want to always have to write each assert from scratch.       ... 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