ContributionsMost RecentMost LikesSolutionsRe: Add optional "Suite Group" level above Test Suites in the SoapUI hierarchy, for better Let me support that request as well! Having only two "levels" (Test Suite, Test Case) above the test steps makes it really difficult to organize your tests, when you have hundreds of those... Re: Option to turn off the SoapUI NG sub-tab Actually I would go so far as to say anything we close should stay closed next time we start R!API (for example the "API Navigator", the "Toolbar", etc.) [Groovy] Cancel / fail a whole TestSuite Today when inside a groovy script you can cancel/fail the execution of the current TestCase, using the testRunner: testRunner.fail("DON'T PANIC") I would like to request a method allowing to do the same, but cancelling the whole TestSuite instead. The reason is that I have some TestSuites with hundreds of TestCases, which all depend of some important preconditions (i.e. some services are available) Checking those conditions can take quite some time, especially if calling those services result in a timeout This means performing a check at the beginning of each test case is not acceptable, it would take too much time (I want my test projects to run as quickly as possible) Re: Customize default "Test Case options"Great news, thank you very much !Swagger: use body model when importing When importing a swagger file which contains some body model, it would be good if R!API could use it to generate the corresponding REST request. Basically, let's say I have a swagger "operation" with the following: apis": [ { "path": "/example", "operations": [ { "method": "POST", "nickname": "handlePost", "produces": [ "application/json" ], "consumes": [ "application/json" ], "parameters": [ { "name": "data", "paramType": "body", "type": "InsertionData" } ], And the InsertionData model defined like that: models": { "InsertionData": { "id": "InsertionData", "properties": { "id": { "type": "integer", "format": "int64", "required": "true" }, "address": { "type": "integer", "format": "int32", "required": "true" } } } } When I import this using Swagger, R!API will create a blank POST request with an empty body: I would expect it to create a default body like this to the request instead: Customize default "Test Case options" 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. Expand the parameters to fill the available viewport size When sending a REST request with parameters, the width of the textfield used to input parameters is fixed (and quite small). Could you modify it to actually expand to the available viewport ? See my poorly edited example in attachment. :-) Re: [Ready API 1.2] Double slash (//) in path Nope, on news on my side :-/ Command-line import of swagger API Today we're generating a swagger documentation of the API provided by our Java and C++ applications. This swagger documentation is automatically generated at compilation time, based on annotations and comments present in the source code. When adding new methods to our APIs (or new APIs altogether), the developer then has to manually import the swagger definitions in SoapUI (using the "new project from swagger definition" feature), then copy-paste the corresponding XML files in all our projects. It would be great if we could automate the swagger-to-SoapUI conversion, using for example a command-line interface or a dedicated executable. This way we could plug this in our Continuous Integration system, and when someone add a new API (or a new method to an existing one) all his colleagues would then benefit from it simply by synching their projects on the latest version available in our version control system. Re: Share APIs between projects We're talking about a couple dozen APIs (we are using ReadyAPI to test a system with lots of applications interacting with each other, and each application have some REST API allowing us to check its state and control it). But the performance problems are not due to the number of API, as far as I know. They are apparently due to the size of our projects (see internal defectSOAP-4680); But we also get performance problems on smaller projects (I'll send you a private message with the URL to a video I made for your support team regarding another issue, so you'll see by yourself).