Version 1.9


  • Now you can debug Groovy script code directly in Ready! API. You can step through the code, pause the script execution on a breakpoint, examine variables and objects in the new Debug Info page of the Groovy Script editor.

    You start debugging by clicking the command on the test step editor's toolbar. The test case and test suite editors also have this toolbar button. When you click it there, Ready! API starts running the test suite or test case and stops on a breakpoint that you set in your Groovy script code.

    For complete information, see Debugging Groovy Scripts.

  • Two new assertions help you verify requests more thoroughly:
  • User experience improvements:
    • The Get Data command now displays properties of the current test suite or test case prior to properties of other test suites and test cases.
    • By default, SoapUI NG now uses the single panel layout instead of showing tabs. You can see the edited test suite, test case, test step or other item in the Navigator panel on the left. To restore the former behavior, use the Preferences > UI > Workspace type setting.
    • Now, after you added a test step to a test case, Ready! API does not display the test step editor automatically by default. To make it visible, simply select the test step in the Navigator on the left. To restore the former behavior, use the Preferences > UI > Show test step editor setting.
    • The main toolbar has a button for the Save Project command.
    • The Debugging tab of the test case editor has been renamed to Step-by-Step Run.
  • The Transaction Log now displays which data source row was used on each iteration of the loop.
  • The JDBC Request test step has a new Pretty print property. If this property is true, Ready! API indents nested elements of XML responses. Otherwise, the data are shown in the form they are received.
  • The Schema Compliance assertion now supports property expansion.
  • The Street Address data generator has a new Max length property. Use it to limit the length of the generated address string.
  • Use the new setting on the Preferences > Default Test Case Options page to define the default property values of new test cases.
  • The Preferences > HTTP settings includes the new Default authentication profile option. It specifies the authentication settings that the request test steps should use by default. Possible values include settings from the parent step, settings specified in the API definition and “No authorization”.

Bug Fixes

  • Sometimes, the Transaction Log did not open results of the TestCase test step. (RIA-61)
  • Long test case and property names were shorten in reports. (SOAP-5563)
  • Switching from the Form view to the XML view in the request editor changed the order of XML elements. (RIA-150)
  • Ready! API was unable to form an XML response view from JSON response data that contained double slash (//). (SOAP-4958)
  • In certain cases, the JSON and XML views did not display some JSON nodes. (SOAP-5729)
  • The “Certificates does not conform…” error occurred when setting an SSL connection to a server that used security certificates generated or signed with obsolete algorithms. (RIA-208)
  • Ready! API could hang if you simulated a request where“WS-Reliable Messaging” property was enabled. (RIA-264)
  • Ready! API could hang when running the DataSink test step if the response contained the $$ or ${ substrings. (RIA-392, SOAP-6246)
  • In some cases, the DataSink test step failed to import column names from an Excel file. (SOAP-5309, SOAP-5666)
  • Deleting the Target step in a cloned Data Loop cleared the Target property of the original Data Loop step. (SOAP-5246)
  • Sometimes, the DataSource test step failed to import property names from an Excel file: some column names were not imported. (SOAP-5732)
  • The DataSource test step that uses the Groovy source type stopped working after the test step editor was closed. (SOAP-5756)
  • When running a test case that had many DataSource test steps loading data from various sources, Ready! API could run out of memory. (SOAP-5911)
  • In certain cases, it was not possible to change the “Stored Procedure” property of the JDBC Request and DataSource test steps. (SOAP-5799, SOAP-6011)
  • The “Result column name case” property of the JDBC Request step was not saved. (SOAP-6004)
  • The JDBC Request test step removed trailing spaces in returned values. (SOAP-5632)
  • Column names returned by the JDBC Request step were not upper-case. (SOAP-5974)
  • The WS-Addressing actions did not support property expansions. (SOAP-4369)
  • Property expansions did not work for the folderPath property of the Create File test step. (SOAP-6099)
  • An error occurred when dragging an XML-RPC request from the APIs panel to a test case. (SOAP-5512)
  • If a REST VirtResponse test step has another test step specified in the “Start Step” property, and if this other step executed during the run, Ready! API also executed the VirtResponse step even if it was disabled. (SOAP-5559)
  • An error could occur when you were opening a request with an attachment for editing. (SOAP-5949)
  • The REST Request and HTTP Request test steps did not fail when they receive invalid response from a server for the first time. They failed only on subsequent runs. (SOAP-5746)
  • Ready! API did not display the Content-Length response header if the response was not compressed. (SOAP-6064)
  • Changing a property value from a Groovy script worked for certain environments only but not for the whole project. (SOAP-5798)
  • The NullPointerException could occur when you were trying to get an access token in the Auth Manager. (SOAP-5396)
  • The “Delete” command applied to multiple assertions did not remove all of them. (SOAP-5744)
  • Users had to reconfigure the Expected property of the Message Content assertion after they cloned the test step that contains this assertion. (SOAP-5787)
  • Applying the Message Content assertion to large responses could cause Ready! API to hang. (SOAP-5888)
  • The XPath Match assertion extracted wrong data from the RawRequest property value. (SOAP-5975, SOAP-5978)
  • JsonPath assertions did not work if the extracted JSON node started with a period. (SOAP-6136)
  • In certain cases, the JsonPath Match assertions did not work correctly. (SOAP-6231)
  • TestRunner logged the same assertion name for all the assertions. (SOAP-6061)
  • Coverage results were not rendered correctly in reports. (SOAP-6012)
  • The test step metrics always reported zeros for the JMS Request test step. (SOAP-4674)
Help and Feedback

You did not find what you looked for?

© 2016 SmartBear Software

Didn't find an answer? Try searching here: