A test case is a collection of test steps that are assembled to test some specific aspect of your service. Test cases provide clearly identifiable units of the functionality that can be tested independently.

The test case can contain any number of test steps. When you run tests, ReadyAPI runs them in sequence. The test case run is successful when none of the test steps fail.

You can arrange any number of test cases in a test suite and even modularize them to call each other for complex testing scenarios.

Use the test case editor to manage test cases: configure their behavior, examine the test run history, debug tests, and so on.

Click the image to enlarge it.

Test Steps Page

The main purpose of the Test Steps page is managing test steps. To learn how to do it, see Managing Test Steps.

Besides that, panels of the page help you modify various test case aspects:

Description – Specifies the text description of the test case.
Properties – Manages the list of test case properties. See the Test Case Properties section.
Setup Script – Specifies a script that is run at the start of a test case run. To learn more, see Setup, TearDown, and Report Scripts.
TearDown Script – Specifies a script that is run when the test case run finishes. To learn more, see Setup, TearDown, and Report Scripts.
Report Script – Specifies a script that is run when you generate a report. To learn more, see Script Extensions.
Report Parameters – Manages the list of parameters used for report creation. To learn more, see Script Extensions.

Other Editor Pages

To learn about	See
Transaction Log	Transaction Log Page
Compare	Compare Page
History	Test History Page
Coverage	Coverage Testing
Requirements	Requirements Compliance
Step-by-Step Run	About Debugging Tests
Test On Demand	Run Tests On Demand

Test Case Properties

Besides editor panels, you can adjust test case behavior by using its properties in the property tabs in the Navigator.

Test Case Properties | View ↓

Name Description

Name

The name of the test case.

Special characters in the name, including (but not limited to) &, -, /, (, and ), may cause issues with reporting.

Name Description

Name

The name of the test case.

Special characters in the name, including (but not limited to) &, -, /, (, and ), may cause issues with reporting.

Custom Test Case Properties

By using the Custom Test Case Properties tab in the Navigator and the Properties panel in the test case editor, you can create any number of properties. These properties are available to other test cases in your project. To manage the property list, use the toolbar:

Custom test case properties can be stored locally in your workspace file by selecting the checkbox on the right. To learn more about it, see Locally Stored Properties.

Test Case Options

Use test case options to configure test case behavior according to your needs.

The test case options are grouped into three tabs, according to aspects they relate to:

Basic – Contains common test case options.
WS-RM – Contains options related to Web Services Reliable Messaging.
Zephyr – Contains options related to Zephyr integration.

Basic

The Basic Options define general behavior for the test case.

Option

Description

Search Properties

Collect properties from previous test steps. This option provides scripting access to all test step properties.

Session

By default, ReadyAPI closes the session after each request. Enable this option to prevent ReadyAPI from closing the session for the entire test case. In this case, ReadyAPI stores cookies received from the server and sends them back in the subsequent requests. This helps you create tests that simulate real user behavior.

Abort on Error

Stops the test run when a test step fails.

Fail Test Case on Error

Marks the test case as failed if a test step fails.

Note:

This option does not stop the test run.

Discard Successful Results

Discards all successful results after the test step execution is complete. Enable this option to use less memory in your tests.
Make sure to keep this option disabled if you use the Assertion test step, otherwise, you will not get the expected result.

Tip:

This option is identical to the Discard PASS Results within Loop option available for the Data Source Loop test step, though the latter affects only the steps within the loop.

Socket Timeout

The duration (ms) of a connection socket. The empty value or 0 sets the timeout to 1 minute.
Default value: 0.

Test Case Timeout

The duration (ms) until Test Case times out. The empty value or 0 does not set the timeout.
Default value : 0.

Max Results

The maximum number of results to keep. Older results are discarded and cannot be asserted with the Assertion test step.
The empty value or 0 means no results are discarded.
Default value: 5.

WS-RM Options

When running a test case containing many requests, it may need to run all requests in the same WS-RM Sequence instead of creating a new one for each request.

The WS-RM Options tab is used to enable WS-RM (Web Services Reliable Messaging) for requests in the test case.

Option

Description

WS-RM Enabled

Enables the WS-RM Sequence

WS-RM Version

A version of WS-RM used by the target service

WS-RM AcksTo

Required. WS-Addressing Endpoint for SequenceAcknowledgement

WS-RM Expires

Defines the duration for the Sequence.

Note:

If empty never expires = "PT0S"

The authorized WS-RM Sequence is shared among all test steps in the test case. The credentials will be used to connect before the first test step and disconnect after the last test step in the test case.

Enabling WS-RM here will generate a WS-RM Sequence for all requests in the test case instead of one for each.

Zephyr

Use the Zephyr tab to associate a test case with a Zephyr test. To learn more, see Zephyr Squad Integration.

Option	Description
Zephyr Test ID	The ID of the Zephyr test to associate a test case with.

Examples

Here are several sample test cases:

Login and Logout Test Case

XML Data Source Test Case

This is a detailed description of the XML Data Source test case from the SOAP Sample Project. This test case demonstrates some of the advanced possibilities of functional testing:

How to use a data source setup to perform data-driven testing, in this case, pulling the data from the response of the preceding request.
How to use Groovy scripts to do a simple interaction with the user.
How to use property expansions instead of the Property Transfers test step for transferring simple property values between properties and messages.

Click the image to enlarge it.

The goal of this test case is to log in, search in a product database, and add the found items to an imaginary shopping cart. It consists of the following test steps:

Start Virt Service – The Virtual Service Runner test step that runs a virtual service.
Properties – Username and Password – The Properties test step defines the Username and Password properties that are used in the test case for parameterizing the login request. Putting them here makes them easy to change.
Test Request – login – The SOAP Request test step that sends a login request to the target service and validates the result. The username and password are specified by using the property expansion that is used to transfer property values from one test item to another.
Test Request – search – The SOAP Request test step that performs a search in the target service by using the session id received in the response to the previous login request. Again, the property expansion is used to obtain the session id from the login response.
Data Source: Item Data Source – In this Data Source test step, we use the XML data source. It takes the response received from the search request and turns found items to a set of data.
PropertyTransfer: Search String – The Properties Transfer test step that transfers the values of the current row of the data source to the following request.
Test Request – buy – The SOAP Request test step that submits the buy request to the target service with the data transferred from the data source as an input and validates the response.
Groovy Script: Log information – The Groovy Script test step that posts information on request results to the Script log.
Data Source Loop: Item Data Source – The Data Source Loop moves the data source to the next row in the source data and continues the test run back to the sixth (PropertyTransfer: Search String) test step.
TestRequest – logout – When the data source does not have available data, the SOAP Request test step sends the logout request. It uses the session id received for the initial login.
Stop Virt Service – The Virtual Service Runner test step that stops the virtual service.

Test Case Editor

Test Steps Page

Other Editor Pages

Test Case Properties

Test Case Properties | View ↓

Custom Test Case Properties

Test Case Options

Basic

WS-RM Options

Zephyr

Examples

See Also

Test Case Editor

Toolbar

Test Steps Page

Other Editor Pages

Test Case Properties

Test Case Properties | View ↓

Custom Test Case Properties

Test Case Options

Basic

WS-RM Options

Zephyr

Examples

See Also