Introduction

IBM® Rational® Functional Tester (formerly known as Rational XDE Tester) provides the ability for you to create your own "super helper" class. This white paper will attempt to answer these questions:

• "What is a super helper class?"
• "Why would we want to use a super helper?"
• "How do we implement our own super helper?"

Back to top

"What Is A Super Helper Class?"

To fully answer this question, we must first discuss object-oriented inheritance, also known as "extension" or "subclassing" in Java.

Java Inheritance

Object-oriented systems allow classes to be defined in terms of other classes. For example, mountain bikes, racing bikes, and tandems are each a type of bicycle, so in object-oriented terminology they are subclasses of the bicycle class. Similarly, the bicycle class is the superclass of mountain bikes, racing bikes, and tandems. This relationship is shown in the following figure.

Subclasses inherit both state and behavior from their superclasses. Using our example, mountain bikes, racing bikes, and tandems share some states such as speed, size, and so on. These common states are captured in the form of variable declarations in the superclass. Common behaviors for bicycles might be braking and changing pedaling speed, for instance. In addition, subclasses can extend the functionality of the superclass by adding their own state(s) and/or behavior(s).

Rational Functional Tester Test Script Inheritance

Now that we understand these relationships, we can discuss Rational Functional Tester test scripts, which are actually subclasses or specializations of a script helper class. Methods in the helper class provide a great deal of capability to the script. These methods give the script the ability to find objects in the object map and execute verification points. The helper class is generated by Rational Functional Tester when you record your script, and is regenerated by Functional Tester as necessary. Since this occurs, you should never modify the helper class by hand, because any user modifications to the helper class will be lost the next time Functional Tester generates it. Each test script has one and only one helper class. Each helper class has one and only one script that extends it.

ALL helper classes must extend the class RationalTestScript. By default, the helper class is a direct subclass of the class RationalTestScript, as shown in the following figure.

Functional Tester provides the ability to insert your own class into this inheritance hierarchy:

A super helper, then, is a class through which you can implement functionality that then becomes available to all Functional Tester scripts whose helper extends the super helper.

Back to top

"Why Would We Want To Use A Super Helper?"

Let's take a simple example. You may choose to implement an Unexpected Active Window (UAW) handler in your scripts to address the situation where a window or dialog other than the one Functional Tester is attempting to access becomes active. In this state, a UAW handler attempts to dismiss the active window so that Functional Tester can continue. Without the handler, Functional Tester will time out waiting to gain access to the object.

A UAW handler is implemented by overriding the base implementation of the onObjectNotFound handler. The implementation details of this solution are beyond the scope of this paper; however, there is an example of this in the Functional Tester help under User Guide > Advanced Topics > Handling Unexpected Active Windows.

This is all well and good, but to make this functionality available to multiple scripts without using a super helper, you would need to paste this code into every script after it was recorded. Another approach would be to alter the template that Functional Tester uses to generate scripts, so your code is included.

There are many drawbacks to both these approaches, not the least of which is maintenance. If you decided to enhance your handler, you would have to edit the code in each and every script that contains the handler. This is not a trivial task if you have dozens or hundreds of scripts in your datastore!

In contrast, the super helper provides a single place for you to put your handler code. The handler method implementation is then inherited by every helper class that extends your super helper. Since the helper class does not override the method implementation, it is therefore accessible to your script. In the rare instance that you don't want your super helper's method available to your script, or if you want some alternate behavior, you can simply override the method in your script.

Back to top

"How Do We Implement Our Own Super Helper?"

Let's continue on with a step-by-step example of implementing a UAW handler (an override of the default onObjectNotFound implementation) in a super helper. The steps we will follow are:

1. Create a test folder to hold the super helper class
2. Create a Java class that will act as our super helper class
3. Implement the onObjectNotFound handler in the helper class
4. Alter the properties of a script to cause the script's helper class to extend our super helper
5. Alter the Functional Tester property setting to make all new Functional Tester scripts use our super helper

Create a Test Folder

The super helper class can be located at the root of our datastore, in a subfolder, or even in an external jar file. In this example, we will create a subfolder called utility in which to store our class.

1. Right click on the root of your Functional Tester datastore and select New Test Folder.
2. In the New Test Folder dialog, name the folder Utilities and press Finish.

Create The Super Helper Class

We will use the Eclipse creation wizard to create an empty class.

1. Highlight the new folder and select File > New > Other..., then choose Java Class from the New dialog and press Next.

2. Complete the New Java Class dialog as follows:

   Type MySuperHelper in the Name box, select the abstract check box, and type com.rational.test.ft.script.RationalTestScript in the Superclass box.

3. Click Finish.

4. Our new class will look like this:

   package utilities; import com.rational.test.ft.script.RationalTestScript; public abstract class MySuperHelper extends RationalTestScript { }

   
   

Implement the Exception Handler

Our handler will override the default onObjectNotFound handler in the RationalTestScript class.

1. Add any additional imports our handler may need. import com.rational.test.ft.script.ITestObjectMethodState;
2. Add our exception handler code into the class.

   Note -- an example of an onObjectNotFound handler can be found in the Functional Tester help files under Advanced Topics > Handling Unexpected Active Windows

   package utilities; import com.rational.test.ft.script.RationalTestScript; import com.rational.test.ft.script.ITestObjectMethodState; public abstract class MySuperHelper extends RationalTestScript { /** * Overrides the base implementation of * onObjectNotFound. Whenever this event * occurs, look through all the active domains * (places where objects might be found). * For HTML domains (Java and other domains * are skipped) finds all the top objects. * If the top object is an Html Dialog, * types an Enter key to dismiss the dialog. * Logs a warning when this happens. */ public void onObjectNotFound( ITestObjectMethodState TestObjectMethodState) { // Implementation of event handler // goes here. } }

   
   

Extend the Super Helper with Our Script's Helper

The script's helper class needs to be altered to extend the new super helper instead of the RationalTestScript class. You may be tempted to browse to the helper and edit it by hand. Resist the temptation! The helper class is managed by Functional Tester and your changes will be overwritten if you hand-edit the helper. Instead, follow the procedure below.

1. Select our script in the Datastore Explorer.
2. Right-click and select Properties.
3. Select XDE Tester Script in the list of the Properties dialog.
4. Type utilities.MySuperHelper in the Helper superclass box.
5. Click OK.

Make Our Super Helper the Default for New Scripts

The preceding procedure only changed a single script's inheritance hierarchy to use the new super helper. Functional Tester has a global setting that allows you to make this configuration the default for all newly created scripts.

1. In the Datastore Explorer, right-click on your datastore and select Properties.

2. Select XDE Tester Datastore in the list box.
3. Type utilities.MySuperHelper in the New Script Helper superclass box.
4. Click OK.

Back to top

A Note on Configuration Management

Your super helper will become an important, shared asset in your testing project. It is therefore imperative that you are able to store it in a robust repository, track and control new versions as they are created, and be able to retrieve old versions when necessary. Rational Functional Tester provides a robust, scalable interface to Rational ClearCase. The use of Rational ClearCase with Functional Tester is beyond the scope of this paper, but it is highly recommended that you manage your super helper class -- along with all your other test assets -- in ClearCase.

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• "What Is A Super Helper Class?"
• "Why Would We Want To Use A Super Helper?"
• "How Do We Implement Our Own Super Helper?"
• A Note on Configuration Management
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers