Prerequisites

Installation of IBM® Rational® Functional Tester, Version 7

Back to top

An overview of Rational Functional Tester project structure

1. Import the sample Rational Functional Tester project (see Download). You will see a script named BaseCase and a folder named util.
2. Switch to the Java™ perspective by selecting Window > Open Perspective > Java. You will see the following three packages:
   • (default package)
   • resources
   • util

The BaseCase script is in the default package, and its helper class, BaseCaseHelper, plus the other configuration files associated with the script are in the Resources package. These two packages are invisible under the Functional Test perspective. You create the util package, along with classes in it. In the following sections, you will use this framework (see Figure 1).

Back to top

A quick glance at the find() method

You might be advised to use the find() method to get a test object when the getMappedTestObject() method does not work. The code in Listing 1 shows the signature of the find() method.

// Finds all candidates that match given search criteria starting at this TestObject
public TestObject[] find(Subitem properties);

The find() method works by comparing certain properties of the test objects with the given criteria to find a set of candidates. You can search a test object by a name/value pair that represents its property or contains one or more properties that will be matched against the children of the starting test object. If the recognition of a test object fails with the default getMappedTestObject() method, you can locate its ancestor first, then find the target test object by calling find() on the ancestor. Obviously, the find() method offers considerable benefit. The script is no longer dependent on the object map. The result of searching a candidate test object is predictable, thus robust. You can find a test object by its property values, which may be simple text. And it's easy to maintain the script.

However, the find() method cannot cover all of the cases when the method getMappedTestObject() does not work. There is not always an obvious set of property values to be matched. The find() method relies on a distinct set of property values. Therefore, if the test object does not have such a set of properties, the method will not function correctly. Although we can try the test objects one by one in the return array to find the correct one, that is not a smart way. And sometimes, it is difficult to find a recognizable ancestor of the test object, so the search has to begin from the top-level object, such as a window. This will reduce the recognition of the test object.

Back to top

Navigation path-based object recognition

Considering the drawbacks of the find() and getMappedTestObject() methods, you need another way to solve the ambiguous cases in Rational Functional Tester object recognition. In this article, we introduce a navigation path-based method to find the target test object. We'll use the application ClassicsJavaA as an example. To make things simple, we suppose that the Place Order button is the test object to find.

After recording the click operation on the Place Order button, you get the following hierarchical structure in the object map that is illustrated by Figure 3. You can see that the Place Order button is a child of the frame. The frame is shown as the main window, and it is where the Place Order button is located. Of course, in this example, you can simply use the find() method to locate the button. However, we'll try another way to resolve this.

Introduction to navigation-based object recognition

Sometimes a tester finds the tested object by visual clues, such as the relative position in relationship to an obvious image. For example, you might find the Place Order button by its position relative to the cover picture of the album. This is a very useful strategy for locating the tested object. Similarly, for a given test object, which is called the anchor object, you can use the Rational Functional Tester APIs to point to any object with a given path. Using the previous example again, you can find the Place Order button by its position near a found object, the picture of the album, and a specific path. Here the term "path" is referred to as the logical distance of moving from one object node to another in the object map.

Navigate through the object map

In the Private Test Object Map for Script BaseCase window, you know that the Place Order button is a child of the main frame. Obviously, this object map does not include all of the components in the main frame. Follow these steps to get a bigger picture of the object map tree:

1. Click Test Object and then click Insert Object(s) on the menu of the main window to open the wizard dialog.
2. Use Object Finder to highlight the main frame and select it.
3. Select Include all available objects on this window and click Finish.

As Figure 4 shows, now you can see that more children of the main frame are added into the object map.

Important:
Although you select the "include all" option, that option does not include all of the children of the main frame. This object map only helps you to get an idea where the Place Order button is located.

You use another tool to find all the children of the main frame. Actually, you used it just now. It is the Insert Object(s) wizard dialog (Figure 4). With this wizard, you can see all of the mappable objects. Follow these steps to locate the Place Order button.

4. Select Test Object > Insert Object(s) on the main window to reopen the wizard dialog (Figure 5)
5. For the Selection Method, select Test Object Browser.
6. Find the Place Order button, guided by the hint of the hierarchical relationship given by the test object map generated just now.

According to the Test Object Browser, you we can see many objects that are missing in the test object map. The order of the objects in the object browser is different from those in the test object map. However, the test object map merely gives you a hint to help you find the current object in the object browser. By following the previous steps again, you can easily find the image node of the album. Then you can figure out the exact path from the image node to the button node. (See Figure 6.)

As Figure 6 shows, the path from the image node to the button node can be described as follows. Notice that the index of the child is very important here.

1. First, move up three levels to the parent.
2. Then move down the FIFTH child of the main frame.

Use APIs to implement the navigation

You now know how to figure out the path between two test objects. In this section, you'll learn how to use APIs to automatically locate the target test object with a given path. The APIs needed for this task are summarized in Listing 2.

/**
* This method returns an array of references to the object's mappable children.
* The references to the objects should be released by calling he unregister method.
* If the object has no mappable children, a 0-length array will be returned.
**/
TestObject[] testObject.getMappableChildren();

/**
* This method returns a reference to the parent object that appears in the object map.
* The references to the objects should be released by calling he unregister method.
**/
TestObject testObject.getMappableParent();

/**
* This method returns the topmost mappable parent object that appears in the object map.
* The references to the objects should be released by calling he unregister method.
**/
TestObject testObject.getTopMappableParent();

For simplicity, we do not use the unregister method to unregister the test objects that are iterated. The ObjectFinder class is the helper class that wraps all of the navigation operations. The UML in Figure 7 shows the relationship between these classes. Notice that the TestObjectNotLocatedException must inherit from RuntimeException for consistency.

Considering that path example, Listing 3 shows how you can write the code to find the Place Order button:

// This method is used to find the button Place Order
public GuiTestObject PlaceOrder() throws TestObjectNotLocatedException{
	// The path we specified to find the button from the album image
	// First move up 3 times, then move down to the fifth child
	String pathString = "P3;C5";
	Path path = null;
	try{
		path = new Path(pathString);
	}catch(IllegalPathStringException illegalpath){
		logError(illegalpath.getMessage());
	}
	
	// Assume that the imageAlbum() is already found
	return new GuiTestObject(ObjectFinder.locateTestObject(imageAlbum(), path));
}

We first specify a path string that describes the path from the album image to the Place Order button. Then we use ObjectFinder class to locate the target test object we want.

Back to top

Tips for better test object recognition

We have already seen how to find a test object in variant ways. We can use the default method to find the test object. We also can use the find() method to find the test object with some given attribute/value pairs. And we can locate the test object with a given anchor object and a path. In this section, we'll discuss how to choose the right method and how to organize the source code of Rational Functional Tester project.

Choose the correct object recognition method

Obviously, the default method has a great tool support. Rational Functional Tester provides powerful tools such as Test Object Map and Script Assure, which greatly ease the complexity of script development, shortening the development time. However, it is the simplicity that some script developers complain about. They think that the tools hide some details that they want to control. The find() method is flexible and lightweight. It offers the script developers much control of the test scripts. That's why it is widely used in the scripts to substitute it for the default method. As discussed above, this method cannot cover all the cases. The navigation-based object recognition method is quite lightweight and efficient. And a key strong point is that it can be used on any occasion. However, it is sensitive to the UI structure.

We'll show you how to use the find() method along with the complementary navigation-based method while still enjoying the advantage of using the tools.

Tips for script organization

Recall the first section about Rational Functional Tester project structure. We know that all the object finding methods are implemented in the helper classes by default. For example, the default method to find the button Place Order button might look like Listing 4.

public abstract class BaseCaseHelper extends RationalTestScript {
	/**
	* PlaceOrder: with default state.
	* .class : javax.swing.JButton
	* accessibleContext.accessibleName : Place Order
	* name : placeOrderButton2
	* .classIndex : 0
	*/
	protected GuiTestObject placeOrder() {
		return new GuiTestObject(getMappedTestObject("placeOrder"));
	}
	
	/**
	* Schubert4_14Jpg: with default state.
	* .class : javax.swing.JLabel
	* iconDescription : Schubert4_14.jpg
	* .classIndex : 2
	*/
	protected GuiTestObject schubert4_14Jpg() {
		return new GuiTestObject(
			getMappedTestObject("schubert4_14Jpg"));
	}
}

Then you create a helper class that extends the default helper class and overrides the default method. It would look like the code shown in Listing 5.

public class BaseCaseUserHelper extends BaseCaseHelper {
	// This method is used to find the button Place Order
	public GuiTestObject PlaceOrder() throws TestObjectNotLocatedException{
		// The path we specified to find the button from the album image
		// First move up 3 times, then move down to the fifth child
		String pathString = "P3;C5";
		Path path = null;
		try{
			path = new Path(pathString);
		}catch(IllegalPathStringException illegalpath){
			logError(illegalpath.getMessage());
		}
		
		// schubert4_14Jpg() is object for the cover image
		return new GuiTestObject(
			ObjectFinder.locateTestObject(schubert4_14Jpg(), path));
	}
}
			

Finally, let the script class extend the user-defined class. In this way, you do not need to modify any existing object finding methods. You just override them, which combines the strong points of existing object finding method.

Back to top

Download

Information about download methods

Resources

Learn

• Explore the Rational Functional Tester Information Center, where you can also take a short video tour.
  
  
• Investigate Rational Functional Tester Plus, which is a software application testing bundle.
  
  
• Visit the Rational Functional Tester area on developerWorks for introductory to in-depth information.
  
  
• Learn about other applications in the IBM Rational Software Delivery Platform, including collaboration tools for parallel development and geographically dispersed teams, plus specialized software for architecture management, asset management, change and release management, integrated requirements management, process and portfolio management, and quality management. You can find product manuals, installation guides, and other documentation in the IBM Rational Online Documentation Center.
  
  
• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
  
  
• Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

Get products and technologies

• Try Rational Functional Tester. The trial download is free but requires registration.
  
  
• Download trial versions of IBM Rational software.
  
  
• Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Get involved in the developerWorks Functional and GUI Testing discussion forum where you can discuss and ask questions about Rational Functional Tester and general testing topics.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

He Gu Yi is a software engineer from the IBM China Development Lab in Shanghai, China. He works on federated integration test projects, and his expertise includes enterprise content management, service-oriented architecture, and test automation.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Prerequisites
• An overview of Rational Functional Tester project structure
• A quick glance at the find() method
• Navigation path-based object recognition
• Tips for better test object recognition
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Functional Tester
• Webcast: IT performance management: Measure, monitor and modify for operational excellence
• Briefing: Quality driven software delivery
• Buy: Rational Functional Tester

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers