Calling Tests

This section provides an overview of calling tests and discusses how to use library and shell tests.

  • Use library tests.

  • Use shell tests.

  • Use parameters with library tests.

  • Share test assets.

If a test uses a sequence of steps repeatedly, you may want to isolate the repetitive sequence of steps and move them to another, smaller test. Doing so enables you to call the steps repeatedly and also make them available to other tests that use the same sequence of steps.

Moving shared test steps to a distinct test (a called, or child, test) provides these benefits:

  • Reduces the amount of recording or development you need to do.

  • Reduces the amount of debugging you need to do.

  • Reduces the effects of development changes that require manual updates to existing tests.

You can use the Test.Exec action to call any other test, but you may be able to manage and identify the relationships between calling and called tests more easily on the PTF Explorer tree if you use library tests and shell tests.

A library test cannot be executed by itself. It must be called by another test.

To make a test a library test, select the Library Test check box in the Test Editor.

Complete these steps to create a library test from an existing test:

  1. Open an existing test.

  2. Identify repetitive steps within the test, copy them from the existing test, and paste them into a new test.

  3. Select the Library Test check box on the new test.

  4. Save the library test.

  5. Remove the repetitive steps from the original test and replace them with a step that uses a Test.Exec action to call the new test.

  6. Save the original test.

Parameters enable you to pass dynamic values from a calling test to a library test.

To use parameters:

  1. Define the parameters in the library test.

  2. Assign values to the parameters in the calling test.

  3. Use the parameters as you would text strings in the library test.

To define parameters in a library test:

  1. Select the Library Test check box in the Test Properties dialog box.

  2. Enter the names of parameters in the Parameter List.

    Parameter names can be up to 254 characters, and can contain only letters, numbers, and underscores.

  3. Click OK to dismiss the dialog box.

The following example shows a parameter list:

Image: Test Properties dialog box with a parameter list

This example illustrates the fields and controls on the Test Properties dialog box with a parameter list.

Test Properties dialog box with a parameter list

In the calling test, place parameter assignments in Test.Exec steps in the Parameters field, separated by semicolons, with no spaces. You can place multiple parameter assignments, separated by semicolons. The last semicolon is optional.

Note: The semicolons must not be followed by spaces.

The following example shows a Test.Exec step that calls a library test and passes three parameters.

Image: Test.Exec step with parameters

This example illustrates a Test.Exec step with parameters.

Test.Exec step with parameters

In the library test, place a %param.parameter_name% construct wherever you want to use a parameter. The parameter is replaced at runtime by the text assigned in the calling test.

Image: Library test steps with parameters

This example illustrates library test steps with parameters.

Library test steps with parameters

Note: Parameters in library tests need to be assigned a value in the calling test, because variables are not automatically initialized. The parameters without a variable initialized use default PeopleSoft values on the page.

If the user makes a call to the library without passing a value for the parameter, the parameter value will be the parameter name. For example, if the parameter is UserName and the value is not set, the value would be %param.UserName%, not blank.

To create a shell test, while in PTF Explorer select Create > Shell Test.

A shell test is a type of test that is meant to be used primarily to call other tests. For this reason, a shell test only supports these actions:

  • Execution actions - modify the behavior of tests during execution. Execution actions include Skip_PageSave, Skip_RunRequest, Skip_Login, StopOnError, and Set_Options.

  • Test.Exec - calling other tests. Test.Exec enables you to call multiple test cases with a test and, using the #Ignore reserved word, skip the test call for certain test cases.

  • DataMover.Exec - calling data mover scripts.

  • Query.Exec - running queries.

  • Log.Message and Log.Screenshot.

  • Variable.Set_Value - manipulating variables.

Organizing component tests into shells enables you to identify large business-process oriented type tests (that is, the type that cross multiple components and online activities). The steps available in shell tests are intentionally limited in order to represent high-level business process flows through called test routines.

PTF variables are global, so you can set a variable in the shell test and use it in the called tests, or you can set a variable in a test and use it in the shell test or other called tests.

Often, test developers, application developers, testers, and others collaborate to develop tests. PTF enables you to send links to tests, test cases, and logs to other users, saving them from having to navigate through PTF Explorer to locate them.

To share the location of a test asset:

  1. Copy the link to the clipboard.

    • In PTF Explorer, highlight the name of a test asset and select Edit > Copy Link to Clipboard.

    • In the Log Viewer, with a log open, select Log > Copy Link to Clipboard.

  2. Paste the link text into a message or document to send to another user.

  3. The recipient copies the text and selects Window > Quick Open.

    The Quick Open feature is available in PTF Explorer, Test Editor, and Log Viewer.

    The system automatically copies the link for the asset to the Quick Open dialog box.

  4. The recipient clicks OK to open the asset.

You can also use Copy Link to Clipboard with the Quick Open feature to locate a folder in PTF Explorer.