Test Automation

Testing is an integral part of any application development process.  An essential element to the test phase is the ability to automate these tests, which not only reduces cost by cutting the amount of time running the test, but also ensures accuracy and test coverage when re-running the tests.  

This article provides an overview of Nexaweb's support for automated testing. It first outlines what Nexaweb has provided for automated testing. It then provides several test scenarios and demonstrates how to build the tests featured in these scenarios using the Nexaweb support. While these test scenarios are applicable to any testing tool, the samples in this article use Mercury's Quick Test Professional 8.2 (QTP).

Background

Third-party products such as Quick Test Professional, Silk Test and Rational Robot are commonly chosen to assist in automating tests, because they provide a solid framework for creating UI level functional tests. While these test frameworks provide mechanism to quickly record and play-back a user scenario, they do not provide sufficient mechanisms to adequately validate the results of the user interation. Although these tools provide access to the UI components that make up the applications being tested, they lack knowledge of the component's API which makes it difficult for you to obtain the information need to accurately validate the tests. The time saved by building tests using the record features of these test tools is often lost over time, since you need to remember the flow of the test to understand it at a later time or to make modifications you need to remember that the three mouse clicks fired on lines 10-12 were required to select the item "Bananas" in a combobox.

Test Script API

With these difficulties in mind, Nexaweb Platform 4.2.2 release provides a Test Script API.  The Test Script API exposes the Nexaweb UI components to the test framework as scriptable objects. This provides a simple documented interface for manipulating and validating the state of the objects. The  APIs are intended not to provide full access to the underlying UI components, but to encapsulate high level user interactions such as list box selections and button clicks. These APIs then make it easy to test the results of selecting each item in a tree, or verifying the contents of a listbox. 

 See the developer guide for more - Test API

Setting up the Client

The Nexaweb Test Script API is packaged as part of the NexawebClient-UITesting.jar. For the application to use this jar, you must change the application's client configuration.

To edit your application's client configuration file:

1. Locate: WEB-INF/nexaweb-client.xml of the application to test.

2. Open nexaweb-client.xml with a text editor.

3. Locate the following entry: <ui-test>false</ui-test>.

4. Change this entry to true: <ui-test>true</ui-test>.

5. Save and close nexaweb-client.xml.

6. Restart the server.

Getting a Test Script Object

The getScriptObject() method and the Object Repository

Nexaweb's Test Script API is exposed through scriptable objects that wrap the underlying Nexaweb component. You obtain these Test Script objects by calling the getScriptObject() method on the underlying Nexaweb component.

The following example shows the use of  the getScriptObject() method in a Quick Test Pro script:

Set labelObj = Browser("Welcome To Nexaweb"). Page("Welcome To Nexaweb").JavaApplet("DefaultJvmDetector"). JavaObject("Some Label").Object.getScriptObject()

In this example, the following Quick Test Pro locator methods locate the Quick Test Pro JavaObject wrapper for the label object named, Some Label:

Once the script locates the QTP wrapper object for the Nexaweb component, it uses the Object propery to access the actual component. It then calls the getScriptObject() method on the actual component. The getScriptObject() method returns the Test Script Object for that object. The script can store the returned Test Script Object in a variable for later use in the test script.  

The find object methods of the Application Script Object

One drawback to using the getScriptObject() method is that you must add the UI components you want to test to the QTP Object Repository. While QTP provides a means for sharing Object Repositories between tests, the overhead of maintaining the Object Repository while you are developing the application may prove costly.  As an alternaitve, the Application Script Object provides a set of find object methods for locating objects within the application. With this approach, you need to add only the Java applet to the Object Repository.

To use the find object method, you must first get the script object for the application object similar to the following:

The following example uses the findObjectById() method to get the Test Script object of the label with ID, mylabel, and to get its current text:

The following example uses the findObject() method to get the Test Script object of a button with the text, Test Button, and to click the button:

Testing the Objects

The Test Script API encapsulates many of the composite objects (for example, combobox, listbox, table, and so forth) and provides a simple interface for interacting with the objects and verifying their content. This section shows examples of how to use the Test Script API to test some of the most commonly used components.

Testing the ListBox

The most common listbox test scenarios include verifying the contents and selecting the items of the listbox.

You can select items of the listbox by location within the listbox, or by a specific list item, text string, or value.

The following table describes the ListBoxScriptObject methods for selecting items: