Applies to ReadyAPI 3.5, last modified on November 26, 2020

This topic describes the changes made to Ready! API 1.9.0.

Overall Improvements

  • Ready! API now supports Java 1.8 and no longer supports Java 1.7.

  • The licensing dialogs and messages have been improved.

  • To help you avoid possible loss of changes that may occur when you are replacing files in the repo with your versions, the Git Integration plugin now warns you about merge conflicts when you are pushing changes to the repository.

  • Ready! API now uses operating-system-specific dialogs for opening and saving files.

  • A number of bugs have been fixed.

SoapUI NG

  • 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 on 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 About Debugging Tests.

  • Two new assertions help you verify requests more thoroughly:

    • HTTP Header Exists – Checks whether the response has the needed custom header or headers.
    • HTTP Header Equals – Checks whether the response header contents match the desired value.
  • 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 is 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 include 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".

  • A number of bugs have been fixed.

LoadUI NG

  • LoadUI NG now supports Oracle monitors. Use them to check your database performance during the load test runs.

  • Now, you can run load tests from computers in the Amazon Virtual Private Cloud. See Using Amazon VPC to Run Load Tests.

  • Multiple metrics can now share the same scale of the vertical axis in charts.

  • The improved layout of controls in the Cloud Agent property inspector makes it is easier to view property values.

  • The New Load Test dialog has a new Default template. It simplifies creating new load tests for users without the LoadUI NG Pro license.

  • A number of bugs have been fixed.

Secure

  • REST security scans now have access to the request body. This lets you check the body parameters of POST, PUT, DELETE and other request types that send values in the request body.

ReadyAPI Virtualization

  • To help you create Virts' operations faster and easier, we added a couple of usability improvements to the Virt's editor:

    • The new Clone command to help you create new operations quickly on the basis of another operation:

      Service Virtualization: New Clone Command
    • The new Add Virt Operation button to make it even more convenient to add operations to new Virts.

  • A number of bugs have been fixed.

VirtServer

  • The new command-line tool -- virtserver-cli.bat/.sh -- to deploy, start, stop and manage Virts on VirtServer. See Command-Line Interface Utility for more information on all the features.

    This new tool is part of the Ready! API and VirtServer installation, you can find it in the tools folder after installing the products.

    You can also use it to deploy, start and control Virts from Maven projects and Jenkins builds.

Highlight search results