Bug Fixes in Ready! API 1.4

Ready! API did not remove temporary files when closing. This could consume up to 100MB for each run (API-1696).

Converting the project to a composite project removed report parameters (SOAP-419).

The Export Root Certificate command in the Discovery window did not work (API-1826).

The Discovery engine did not capture custom header fields (SOAP-2038).

Ready! API failed to generate coverage reports in XML format (SOAP-4148).

Ready! API could hang when generating the Form view for requests that have lots of parameters (SOAP-974).

Using the Move Up and Move Down buttons in the custom properties of the JDBC and AMF Request TestSteps causes the property editor to freeze (SOAP-1196).

When you copied a request from Projects to a TestCase, Ready! API did not transfer JMS headers (SOAP-1238).

When exporting WSDL definitions to XSD files, Ready! API formed .xsd file names incorrectly (schema_1_2_3_4_... .xsd). As a result, the file names got too long and could not be used (SOAP-1289).

The DataSource TestStep has some Load Testing settings. Ready! API did not ignore these settings during regular (non-load) test runs. This caused Ready! API to hang (SOAP-1317).

The XPath Match and XQuery Match assertions did not work if their XPath (or XQuery) expression returned a collection (SOAP-1335).

An error occurred when Ready! API tried using Hermes JMS for working with Apache ActiveMQ servers (SOAP-1435).

Ready! API did not encode the endpoint correctly, if this endpoint (URL) contained the $ character (SOAP-1603).

The Message Content assertion always considered the verified value as a string. So, certain conditions in it (like <, <= or >) worked incorrectly for numerical values in responses (SOAP-1604).

The TestRunner command-line script did not generate PDF reports (SOAP-1962).

It was impossible to add the JMS Status and JMS Timeout assertions to the REST Request TestSteps (SOAP-1991).

The assertion dialogs resized incorrectly (SOAP-731).

Ready! API did not update data in the .svn directory appropriately when a user renamed a composite project. This causes to issues when working with the Subversion source control (SOAP-2182).

Property expansion did not work for parameters of the QUERY type in REST requests (SOAP-2255).

The Get Data command that you use to insert a property value into request parameters and TestSteps properties did not display a confirmation dialog if the destination edit box did not have the insertion point or if the inplace editor in a grid was not active (SOAP-2332).

The XML view of the request editor did not display JSON data (SOAP-2701).

Ready! API did not allow copy values from the JSON and XML response views (SOAP-2865).

The context menu of the JSON response view did not have commands for working with the contents (SOAP-3665).

The JsonPath Match assertion did not check arrays in JSON responses (SOAP-2831).

The JsonPath Match assertion did not work for JSON fields, whose names started with $ (SOAP-2831).

Ready! API’s Maven plugin could hang if the .pom file listed multiple projects and did not list test suites and TestCases (SOAP-2604).

The Schema Compliance assertion did not work correctly for certain WADLs (SOAP-2833).

The WS-I compliance failed if the HTTP response code has brackets around it (SOAP-1840).

On Macs, the assertion selection dialog could freeze after the first click on it (SOAP-2706).

The Refactor Definition command ignored the state of the Create backup check box and did not back up the project. This check box is visible when you call the command for SOAP projects (SOAP-2850).

The Scheme Compliance assertion could fail checking WSDLs with the xsi:type="xs:string" declarations (SOAP-2873).

The Clone command could clone a wrong TestSuite if there were several projects in the Navigator panel (SOAP-2882).

Cloning the Assertion TestStep failed if the target TestCase did not have needed properties (SOAP-3843).

Moving TestCases up and down in the Navigator could cause an error at design time (SOAP-3086).

It was impossible to rename a TestStep, if you moved it up or down in the Navigator (SOAP-4068).

The DataSource TestStep failed to retrieve data from a JDBC source if the properties (columns) had auto-generated names (SOAP-3041).

The DataSource TestStep editor cleared property values when you changed the DataSource type (SOAP-3845).

Ready! API always created a security header if a TestCase used an environment. The security header was created even if the environment’s WSS-Type setting was None (SOAP-1555).

The Load Properties command did not update the custom property values if the Custom Properties list included read-only properties. This happened, for example, when loading property values of a SOAP request (SOAP-3306).

Ready! API failed to load WSDLs on some computers that connected to the Internet via proxy (SOAP-3575).

Ready! API failed loading WSDLs that included relative paths to other files (SOAP-3682).

Ready! API failed loading WADLs with duplicated resource paths (SOAP-3858).

Switching from the Form to XML request view created an element instead of an attribute for some complex types (SOAP-3716).

Ready! API failed to open the request editor for certain requests (SOAP-3877)

If the tested API supported both NTLM and Negotiate authentications, Ready! API always used the NTLM authentication settings for the simulated requests. This happened even if request properties required using SPNEGO/Kerberos authentication (SOAP-4143).

Ready! API failed to transfer binary data from a response to the parameters of subsequent requests (the transferred data was corrupted) (SOAP-4151).

The DataSink TestStep corrupted responses containing the ${ } characters when saving the response data to a file (SOAP-4167).

It was impossible to specify a Tibco session in the JMS endpoint dialog (SOAP-4155).

Right after you had added the HTTP Request TestStep to your TestCase, the Run button in the TestStep editor was disabled (SOAP-3988).

It was impossible to specify a value of a DataSink TestStep’s property if the DataSink type was SubReport (SOAP-4270).

There was a misprint ("WADL location") in the "WSDL Definition" section of a SOAP project properties (SOAP-1279).

A number of more minor bugs and misprints have been fixed.

JsonPath assertions were unavailable on agents.

Ready! API failed starting distributed load tests on agents located in the Amazon cloud (LOADUI-3017).

LoadUI NG did not trigger load testing events (like LoadTestRunListener.loadTestStarted, LoadTestRunListener.beforeTestCase and others), so the appropriate script event handlers were not called (LOADUI-3038).

The DataSource TestStep in target TestCases did not work (LOADUI-3278).

In certain cases, LoadUI NG could run load tests only one time and failed to start subsequent runs.
The agents that reside on the same computer, where Ready! API is installed, could stop responding after you run load tests several times. (LOADUI-3323).

If you use load testing event handlers, LoadUI NG collected statistics only for the first test run. It did not gather anything for the subsequent runs (LOADUI-3372).

Agents did not run on headless Red Had Enterprise Linux machines (LOADUI-3412).

A few minor issues with the LoadUITestRunner have been corrected (LOADUI-3546, LOADUI-3228).