kbw
Contributor
Joined 15 years ago
User Profile
User Widgets
Contributions
ReadyAPI 2.5.0 moved the soap/rest request run button's position - Please put it back on the left
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.3.6KViews9likes2CommentsRe: Junit style report not being accurate in Data-Driven tests
Agreed with this. And it's not only for Junit style reports, it's for any form or reporting, including the transaction log, or the new Dashboards. They all report that 1 test case ran. This would preferably be an option either the test case or on the datasource step itself. I lean toward the datasource, since you might have multiple datasources in the test case and one of them is the main driver of what constitutes a real test case. FYI, others have complained about this too: https://community.smartbear.com/t5/SoapUI-Pro/Ready-API-junit-reports-to-show-each-datasource-row-as-testcase/td-p/1295422.3KViews0likes0CommentsRe: Improvements for property scoping
In older versions of SoapUI property expansions were limited to be within the test case or it's direct ancestors (suite, project, and global). So, they acted the way you describe wanting them to act. However, in more recent versions, SmartBear has enhanced property expansions to be able to get data from any property in the project, whether it's in a direct ancestor or not. This is NOT an illegal reference (even though I agree with you that it generally isn't necessarily a wise reference). If the Maven plugin had issues with your expansions, then what you hit was actually a bug in the Maven plugin, not a ReadyAPI bug.1.3KViews0likes0CommentsRe: The various panes and view windows should remember their sizes between sessions
Yes, ReadyAPI has never been changed to make it remember people's setups. This is in related to any pane or dialog. Compare this to most other IDEs, such as Eclipse, QTP, IntelliJ, which remember how you have adjusted all or almost all, of your panes and which items you may have enabled/disabled, etc. Examples of things that you can resize in Ready API, but that it doesn't remember between restarts (this is not exhaustive): 1. The width of your Navigation Pane 2. The height of the properties sub-pane inside the Navigation pane 3. The size of the xpath assertion dialog 4. The details pane for services in Service V area (fyi, the Service V area needs a LOT of UI work, a lot of the choices that were made for the ReadyAPI re-work of this really waste loads of space) 5. The areas that a couple people mentioned in comments Etc.4.2KViews0likes0CommentsAdd optional "Suite Group" level above Test Suites in the SoapUI hierarchy, for better organization
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.7.7KViews11likes4CommentsRe: Add a optional "Category" level above Test Suites in the SoapUI hierarchy, for better
Thanks Sanj, Though, tags are different. They help filter test cases within a given test suite. What I'm referring to is a way for organizing groups of test suites themselves. Perhaps "Suite Groups" or "Suite Categories" would be a better term than just "Categories". Regarding submitting feature requests via support. Yes, I've submitted requests there sometimes, though their support form does encourage people to submit feature requests here in the forum instead, to see what kind of interest there is in the ideas.7.7KViews0likes0CommentsDEFECT: Can't see content of received requests from the REST Mock transaction log
When running REST Mock listeners in SoapUI 5.3, I've found that we cannot double-click the request from the transaction log to see it's contents--nothing happens. Compare to Soap Mock listeners, when you double-click them, an extra window opens that allows you to see the message and response. This is only a problem in SoapUI 5.3. ReadyAPI does correctly allow you to see the content of received requests for REST mock listeners from the transaction log. Reproduce: In SoapUI 5.3 run a REST Mock listener Send a message to it In the listener's transaction log, double-click the entry for the received request to try seeing it's contents791Views0likes0CommentsKeep the same message tab open when switching between ServiceV Requests/Responses
When you have several requests that came to a ServiceV mock listener, and you're looking at them in the transaction log, it would be nice if as you looked at each one, that the tab that you selected when viewing a message (e.g. JSON or Raw) remained selected when you clicked on the next message to view, instead of always switching back to XML each time you click then ext message.1.7KViews1like0CommentsRe: Share APIs between projects
I like this idea, it's something that I've been thinking about too. It's not just a performance thing, it's also an organizational thing--test suites are pretty flat in a single project, so it's clunky to put different APIs that each might have a number of test suites for themselves all into a single project when most of their tests are exclusive of each other. However, when those APIs do interact, either directly or indirectly, it would be useful to have access to the APIs from a central place instead of having to replicate and maintain them in each project. If SoapUI projects had more nesting ability of test suits, then that would even be enough for me, rather than keeping projects separate. That would make keeping test suites for separate APIs in the same project easier to organize (the current test suite structure is too flat for this). Actually... I'll look to see if there's such an enhancement request and log one if there is one yet. Edit: Just added the FR: https://community.smartbear.com/t5/ReadyAPI-Feature-Requests/Add-a-optional-quot-Category-quot-level-above-Test-Suites-in-the/idi-p/1476063.8KViews0likes0Comments- 2KViews0likes0Comments