Handling ambiguous recognition

In some situations during playback, might not be able to differentiate between two similar objects in the software that is being tested. This topic describes handling these situations.

For example, in HTML applications when more than one instance of a browser is active, differentiating one browser from another based on toolbar actions is impossible if the actions are recorded as they are in these examples:


BrowserToolbar_Back().click()
BrowserToolbar_Forward().click()

In cases like this, HCL OneTest™ UI avoids ambiguous recognition by locating the toolbar button in the browser that is identified by its currently loaded document which is referred to as an anchor for the target object. For example:


BrowserToolbar_Back(Browser_htmlBrowser(Document_MyHomePage(),
  DEFAULT), DEFAULT).click();

The back button on the toolbar is anchored by the browser, which is anchored by the document named My HomePage. However, this example would not work if each instance of the browser has the same loaded document. Note that the helper script methods that take an anchor as an argument also require another argument that specifies the component's state (the DEFAULT argument in the example above). The default state for HTML objects is LOADED. For HTML components, the states LOADING and UNINITIATED are also possible. The default state for Java™ objects is SHOWING and ENABLED. Other supported state flags for Java™ objects are NOT_SHOWING and DISABLED.

In addition, you can identify the browser instance by using a TestObject reference for it, invoking the find method on the browser as follows (remember to unregister the test object when you are done).:


TestObject browserOne = Browser_htmlBrowser(Document_MyHomePage(),
  DEFAULT).find();

The browser toolbar commands in the test script would look like this example:


BrowserToolbar_Back(myBrowser, DEFAULT).click();

Another situation where ambiguous recognition can be an issue is when a test has more than one application running at the same time. During playback, commands such as b5().click() are ambiguous. Because the startApp command returns a process test object, this reference can be used to specify which application a particular command applies to. For example:


ProcessTestObject p1 = startApp("SwingTest");
ProcessTestObject p2 = startApp("TryIt");
...
//b5().click(); ambiguous on playback; which application?

b5(p1, DEFAULT).click();

In the last line of the example, the process test object functions as an anchor to locate the desired application. Note that calling the unregister method for a process test object is unnecessary.

Ambiguous recognition can also occur in scenarios where two instances of the same control exist with identical sets of recognition properties. In such a case, the AmbiguousRecognitionException exception is thrown during playback. To handle the exception and to resolve which control needs to be clicked, you can use this code:

public class AmbiguousRecognitionTest extends AmbiguousRecognitionTestHelper
{
@Override
public void onAmbiguousRecognition(
ITestObjectMethodState testObjectMethodState, TestObject[] choices,
int[] scores) {
// TODO Auto-generated method stub
testObjectMethodState.setFoundTestObject(choices[0]);
// super.onAmbiguousRecognition(testObjectMethodState, choices, scores);
}
public void testMain(Object[] args) 
{

aButton.click() // There are two aButton test objects visible on the screen, click the second button. 

}
}

In this example, the second instance of the control is clicked.