IBM Rational Functional Tester Proxy SDK Reference

Functional Test, Java Scripting Overview

See:
Description

Packages

com.rational.test.ft.domain
com.rational.test.ft.domain.java
com.rational.test.ft.domain.java.awt
com.rational.test.ft.domain.java.jfc
com.rational.test.ft.domain.java.swt

Functional Test, Java Scripting Overview

IBM Rational Functional Test, Java Scripting is a component of the IBM Rational Functional Tester offering. You can use Functional Test, Java Scripting to test Java, HTML, .NET, and WIN32 applications through their user interfaces. Functional Test is cross-platform and runs on the following operating systems:

• Microsoft Windows (record and playback)

• Linux (playback only)

Functional Test is cross-browser and supports Microsoft Internet Explorer, Firefox. Much of the Functional Test functionality is made available through the command-line interface. For example, you can edit a verification point data file from the command line.

The sections that follow provide an overview of the Functional Test test framework. For details about classes and interfaces, you can use the provided links to access the Functional Test API Reference.

About TestObjects

Like IBM Rational Robot, Functional Test supports a recorder that captures actions in the GUI and creates a Functional Test script. The scripting language is Java. Functional Test uses TestObjects as an indirect means of accessing and managing objects visible in the application-under-test. Functional Test scripts interact with the objects in the application-under-test through classes that extend TestObject. The TestObject class contains properties and methods that enable Functional Test to recognize and manage objects during playback.

Several important subclasses extend TestObject and form the foundation of the Functional Test test framework, as shown in the following diagram:

GuiTestObject is the base class for modeling all objects in the application-software-under test that have a graphical user interface (GUI). The SubitemTestObject class models the subitems that are contained in other objects, for example, lists. A ProcessTestObject is created every time Functional Test initiates an application. Functional Test models objects into groups called domains. Typically, each HTML browser has its own domain instance, as does each running Java Virtual Machine (JVM). Windows and .NET applications have a domain instance that Functional Test dynamically creates as needed or requested. The DomainTestObject class provides access to information about these domains.

Each TestObject contains a reference to its corresponding object in the application-under-test. The reference either points directly to the object or points to a uniquely identified description called a MappedTestObject. A MappedTestObject is a collection of name/value pairs that describe the properties and expected values of a component in the application-under-test. Functional Test stores these objects together to create an object map, which serves as an approximate representation of the hierarchy of objects in the application-under-test.

About Functional Test scripts

A Functional Test script is a text file that contains statements that Functional Test generates when you begin to record the script. When you play back the script, Functional Test recreates the functional test by executing the statements in the script. A Functional Test script include three categories of statements:

• Statements that emulate user actions

• Statements for validating application state (verification points)

• Various miscellaneous statements, such as the command for starting an application

A Functional Test, Java Scripting test script is a Java source file that defines a Java-language class, as shown in the following example:

     import resources.test3Helper;

     import com.rational.test.ft.*;
     import com.rational.test.ft.object.interfaces.*;
     import com.rational.test.ft.script.*;
     import com.rational.test.ft.value.*;
     import com.rational.test.ft.vp.*;

     /**
      * Description : Functional Test Script
      * @author Your name
      */
      public class test3 extends test3Helper
      {
   
     /**
      * Script Name : test3
      * Generated : Jul 10, 2001 3:44:18 PM
      * Modified : Jul 10, 2001 3:44:18 PM
      * Description : Functional Test Script
      * Original Host : Windows 2000 x86 5.0
      *
      * @since 2001/07/10
      * @author Your name
      */
       public void testMain (Object[] args)
       {
       ...
       }
     }

The first portion of a Functional Test script contains import statements, which specify the packages or classes required for compiling the script. The information between /** and */ is a Javadoc comment. This text is read by the Javadoc compiler and appears as a tool tip when you use the Software Development Platform Java Editor.

Each Functional Test script class extends a class, which is called a helper class (in the preceding example, test3Helper). Functional Test uses the helper class to access the TestObjects referenced by the Functional Test script. The helper classes extend RationalTestScript, which is the base class that provides the functionality for script execution.

Every Functional Test script has a method called testMain, which is the starting point for script execution. This method overrides an abstract method defined in the RationalTestScript class. The testMain method in the script consists primarily of user-action commands and are implemented as methods on TestObjects. The types of statements in a Functional Test script are described in detail in the sections that follow.

Start applications under Functional Test

The first statement in a Functional Test script that has not been manually modified is the startApp command. Because Functional Test scripts must be portable across different computers and operating systems, Functional Test stores startup information in a configuration file rather than in the script. The startApp command in the script references a symbolic name for the application-under-test, as in this example:

     public void testMain (Object[] args)
     {
       startApp("SwingSet");
       ....
     }

You specify application information in the Edit Configuration Info dialog box. The symbolic name is stored in the local configuration file (configurations.rftcfg), which points to either the location of the main class for Java programs or the location of the executable file.

Identifying user-action commands in the Functional Test script

User-action commands include all actions performed on GUI objects in the application-under-test during recording. For example, clicking a button, selecting an item in a list, or entering data into a form. User action commands in a Functional Test script reflect the type of object being acted upon. The object reference in the command is followed by a method name that specifies the action taken against the object. In the following example, click is the method (user action) that acts on the object (button b5) during playback:

     public class test3 extends test3Helper{

       public void testMain (Object[] args)
       {
         startApp("ButtonClick");
         b5().click();

The user-action command in the preceding example calls a method in the helper script class that searches the object map for the MappedTestObject associated with b5. The MappedTestObject contains the recognition properties for the corresponding object in the application-under-test. The helper method b5 constructs a GuiTestObject associated with button b5. On playback, Functional Test uses its object manager to find the right object in the GUI to click. The click method is one of many methods that simulate a user action supported by the GuiTestObject class.

Another form of user-action commands in your test scripts is shown in this example:

     ProcessTestObject pid = StartApp{"TryIt");
     b5(pid, DEFAULT).click();

This form of user-action command takes two arguments. The first argument indicates the context of the command. In the preceding example, pid is a reference to the ProcessTestObject, which is associated with the application that is running. The second argument indicates state information, such as whether the object is visible. The various possible values for state are defined in RationalTestScript.

Identifying verification point commands in the Functional Test script

During recording, a verification point captures information about a specified GUI component, for example, its size or its position. Functional Test records a statement in the Functional Test script for each verification point. The verification point information is stored in a baseline data file. When the script plays back, the verification point captures the relevant data associated with the object and writes it to a data file. The data captured during playback is compared against the baseline to determine any differences.

Verification point commands appear in the script with the name that you assign to the verification point when you record the script. This name is always followed by "VP().performTest();", for example:

     CorporateOrgChartVP().performTest()