Contents


Test dynamic Web applications with IBM Rational Functional Tester scripts that can handle application changes

Build clean, lean resilient scripts that also save time and repository space

Comments

Changes challenge automated testing

The Internet and World Wide Web have become integral parts everyday life and business. Of course, most Web pages and Web applications that we see today are dynamic. Those changing pages make automating the testing of Web interfaces quite challenging. IBM® Rational® Functional Tester can help you automate tests even while the applications under test and the pages they link to continue to change.

Including actions on objects without adding to the object repository

Your test might include selecting random dates in a date-selection window. For the test to pass, the specific date chosen at random must be recognized. The date selection object shown in Figure 1 and the typical strategy of adding the links to the object repository poses problems:

  • To click a date link, the date links must be added to the object repository; otherwise, no dates can be selected during the test run.
  • If the chosen dates are random, then you need to add to the repository all 365 days as date links.

Adding all these dates would require that you spend your test-development time adding the links and filling with the object repository with hundreds of date links.

Figure 1. Date-selection window
A calendar display for selecting a month and day

A smarter solution for objects

Rather than relying on so many links, you can you create the objects dynamically and use them to include this date-selection window, plus include the possibility of using any date in a year. This also makes your script resilient enough to permit using different dates. This method does not require that you add any date objects to the object repository.

Important:
Unregister the dynamically created objects after you have used it and no longer need the object. Rational Functional Tester unregisters bound references when the entire playback ends, not when the script ends. When a bound reference to the object exists, Rational Functional Tester prevents the object in the application from being entirely free. If the object continues as unregistered, the garbage collector does not collect the object because Rational Functional Tester refers to it. This reference prevents the release of memory, which can lead to unpredictable behavior

To create the date-selection object dynamically, you need to see the properties of the object first:

  1. To add the object so that you can see the properties of the object, select 19 for 19 July 2009.
  2. Open the object repository of the script where you added the link. The properties are shown in Figure 2. The date link is shown as javascript:dateHandler(%2019,7,2009%20);
Figure 2. The object map editor with the test object hierarchy and the object properties
The object map editor shows the link value
The object map editor shows the link value

You can use a regular expression for the date link, and determine the object at run time. In the Value column, type this value for the object: javascript:dateHandler(%20\\d+,\\d+,\\d+%20);

The regular expression includes the 35 possible date links that are available in Figure 1. However, you need to add all possible dates in a year.

Note:
See the Rational Functional Tester Information Center for details about using regular expressions.

  1. Expand the regular expression to include all possible dates in a year (see Listing 1). By writing the regular expression this way, the test can accommodate any specific date.
Listing 1. Sample code for clicking the date link
publicvoid clickReqDate(String date, String month, String year) 
throws Exception{
	
	RegularExpression dateHrefReProp = new
	RegularExpression("javascript:dateHandler\\
	(%20"+date+","+month+",\\d+%20\\);",true);
		
	//Finding the object from the dialog which has properties of
	//class as Html.A and href as dateHrefProp
	TestObject [] dateObjs = find(atDescendant
	(".class","Html.A", ".href", dateHrefReProp));
		
	System.out.println(dateObjs.length);
		
	//converting the testObject to GuiTestObject
	GuiTestObject dateObj = (GuiTestObject)dateObjs[0];
	dateObj.waitForExistence();
		
	//getting the text property of the date at runtime.
	String runtimeDate= (String) dateObj.getProperty(".text");
	System.out.println("Date: "+runtimeDate);
		
	//Comparing the String that is passed through the method with that of the 
	//date String that we got at runtime.
		
	if(runtimeDate.equalsIgnoreCase(date)){
		dateObj.click();
	}
		
	//unregistering of the object.
	dateObj.unregister();
		
	}
  1. Delete the object that you used to select the single date of 19 July 2009.
  2. For selecting the date of 19 July 2009, call the method with these parameters specified: clickReqDate("19","7","2009");
  3. Unregister the object that you create dynamically, which is also good coding practice. See the final section of Listing 1 for the command to unregister the object.

Specifying navigation clicks can clutter a test script and waste your valuable time. For example, navigating to the page shown in Figure 3, requires that you click four to five links: Rational > Downloads > Plug-ins > Ready for Rational Plug-in Central. Your test would include the code in Listing 2. That code represents the navigation to one page. Consider how many pages users go to in applications under test.

Figure 3. Sample site showing the navigation
Web page shows selections for opening another page
Web page shows selections for opening another page
Listing 2. Links in a test script
link_rational().click();
link_downloads().click();
link_plugins().click();
link_rationalPluginCentre();

After selecting the final link, a tester might need to navigate to a similar link in WebSphere. The test requires clicking four to five additional links. Most of the script contains link coding.

A smarter solution for navigation

In a storage domain product that I currently work on, we spend most of the time navigating to different pages. If we follow the typical procedure of recording clicks in the test script, clicking the links would constitute 70% of the script code.

However, you can reduce the links in the script and create a resilient script that can function even as various sites are chosen. We created XML code that maintains the parent-child structure of the links and tabs. Furthermore, we developed a method to click the required link by getting the parent-child information for the link from the developed XML code.

The XML code for clicking the Ready for IBM Rational Plug-in Central link, as shown earlier in Figure 3, has the hierarchy shown in Listing 3.

Listing 3. XML code that shows the link hierarchy of a Rational Web page
<link_IBM_HomePage>
	<link_rational>	
	<link_downloads>
		<link_trialDownloads></link_trialDownloads>
		<link_onlineTrials></link_onlineTrials>
		<link_supportDownloads></link_supportDownloads>
		<link_plugins>
		   <link_ibmPlugins></link_ibmPlugins>
    		   <link_rationalPluginCentral></link_rationalPluginCentral>
               <link_webspherePluginCentral></link_webspherePluginCentral>
		</link_plugins>
	
	</link_downloads>
	</link_rational>
</link_IBM_HomePage>

In your test, suppose that you want to navigate to the Ready for IBM Rational Plug-in Central page. You would follow these steps:

  1. Create XML code that captures the hierarchy of links. (See Listing 3.)
  2. In your test script, use this method:
    gotoPage("link_rationalPluginCentral");


Adding this single-line method replaces five link lines similar to those lines in Listing 2

The gotoPage(String) method first checks whether link_rationalPluginCentral is available on the current Web page. If the link is available, the method clicks the link. If the link is not available, the method checks for the parent of the object, link_plugins. If that page is not available, then the method checks for its parent, link_downloads, and so on up the hierarchy.

You do not need to include all of these links in your script, and you can reuse the XML hierarchy code and methods to further enhance efficiency.

  1. After you perform the required operation on the Plug-in Central page, to move to a similar page for WebSphere, we can just call this method: gotoPage("link_webspherePluginCentral");

Tip:
To open the Plug-in Central page for WebSphere page, you must specify the navigation in the XML hierarchy similar to the one shown in Listing 3.

Summary

You can build clean, lean, and resilient scripts by incorporating these practices:

  • Add only the required objects to the object repository to keep the repository clean. Creating dynamic objects and acting upon them as required reduces test dependency on the object repository, which enhances object recognition and reduces maintenance significantly.
  • Make your scripts resilient when applications change by including regular expressions and XML link hierarchies. The tests can tolerate constantly changing objects and navigation.
  • Increase flexibility and reduce the package maintenance that dynamic Web applications demand by rethinking the way that you include objects and navigation.

Spend more time testing and less time adjusting scripts to the inevitable changes in Web applications.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=426554
ArticleTitle=Test dynamic Web applications with IBM Rational Functional Tester scripts that can handle application changes
publish-date=09102009