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)
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 extendTestObject. 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.
Starting 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()