**The following article provides brief introduction to a heavily
used aspect of Rational Functional Tester(RFT). The reader is expected
to have basic knowledge of RFT** .
Introduction -
Rational Functional Tester (RFT) provides
user with a "Recorder" that, as the name suggests, records user
actions on an Application Under Test(AUT) to create a script and this
script can be played back by RFT to perform the same actions back on the
AUT.
The script when generated with the help of the Recorder is
backed up by an Object Map which consists of Objects that correspond
to the actual control that the recorder interacted with while recording.
These
objects in the object map are representations of the controls in the
AUT and are stored with a hierarchy and set of properties ( called
Recognition Properties for the object).
During Playback , the
playback engine uses this hierarchy and recognition properties to find
the control in the AUT and then performs the specified action on it.
For example, the following shows code snippet of a script that performs a click on a button.
okbutton().click();
This
statement has two parts to it , first one being the okbutton() , if
you notice it is not a variable but a method , this method (which is
implemented by the Helper class of the script) finds the actual control
in the AUT using the properties and hierarchy stored in the object map ,
once the object is found the the operation i.e click() is performed on
it.
Using Dynamic Scripting -
The
above mentioned scenario is a traditional usage of the Rational
Functional Tester as a testing tool. Now, lets proceed to the topic that
is heart of this article ... Dynamic Scripting.
Rational Functional
Tester also gives you capability to hand-code your script , so that
you can define the object you are looking for and tell RFT to perform
whatever action you wish to perform on the actual object.
When
you do so you are no longer bound to a static object map , your script
itself would determine what are the properties of an object and how to
look for it.
Let me explain it with an example again.
Following code snippet shows how we can use the find() api to find the search Text box on the google search page.
public void testMain(Object[] args)
{
Property p1 = new Property(".class","Html.INPUT.text");
Property p2 = new Property(".name","q");
Property[] properties = {p1, p2};
TestObject[] candidates = find(atDescendant(properties));
System.out.println("Found "+ candidates.length + " objects");
if( candidates.length ==0)
{
System.out.prinltn("No object found with the specified property set ");
return;
}
//Something found , perform some action.
((GuiTestObject)candidates[0]).click();
((TextGuiTestObject)candidates[0]).setText("hello world");
unregisterAll();
}
testMain()is a method that is invoked by RFT playback engine.
Property
defines a property name-value pair ,these properties could be
Properties that are exhibited by the control or may be defined by RFT.
For
eg: ".class" property is defined by RFT and corresponds to the "tag"
of an element , in the example above ".class" "Html.INPUT.text"
corresponds to the html tag <input type=text>
The second
property that is being used above is the ".name" property which is
same as the "name" property of the <input tag>, so instead of
using ".name" you could very well use "name" as the property name.
Next
we have defined an array to hold this property which is what the one of
the forms of find()api expects, there other forms of find()api which
also expect the name and value pair directly so you could specify the
properties as :
find(atDescendant(".class","Html.INPUT.text","name","q"));
The
find()api returns an array of TestObject which match the specified
property set so its upto you to decide which one to pick ,or perhaps you
should give more properties or unique properties so that we get a
single candidate as a result (if applicable).
Proceeding further,
find() does not accept the property directly , the find expects a
Subitem( a class that belongs to RFT)..this subitem is what is returned
by the method - atDescendant and the other like atChild,atList etc.
These methods (atD
escendant,atChild,atList) tell whether to search for the given property set at Descendant Level , or Child level, or through a list.
atChild()
will be faster then atDescendant() as it will only search at the direct
child level unlike atDescendant() that is going to be exhaustive
because it is going to drill down to each child and its children until
there is none left.
atList() gives guided path for the object we are looking for.
You have to have good familiarity with the Application Under Test(AUT) in order to make a good use of the find()api.
find() api can also be called on another TestObject and in that case that TestObject becomes the starting point for the search.
By default RootTestObject becomes the parent for the find()api to start the search with.
so the statement:
find(atDescendant....)
is equivalent to
getRootTestObject().find(atDescendant...)
If we were able to find the objects (as returned by the find() API) next we need to perform some action on it.
Note
that the find() api returns an Array of TestObject which may not
expose the required functions as it plain test object to perform
some GUI related action like click() ...
as done in the statement,
((GuiTestObject)candidates[0]).click();
,we must typecast it to a .. GuiTestObject .
The Next statement :
((TextGuiTestObject)candidates[0]).setText("hello world");
again typecasts the TestObject to TextGuiTestObject because now we want to invoke a "text" related operation .. i.e setText().
So you should know what kind of different TestObjects RFT provides( the API help has documentation on each one of them) .
Moving ahead there is a call to remove the binding of the returned testobjects as a result of find()api, through the call to :
unregisterAll();
the other forms of this API are:
unregister(candidates); //where candidates is an Array of TestObject returned by the the find()api.
TestObject.unregister(); //Where TestObject is an object found by the find() api.
It
is important to unregister the objects once done using them because
unless you free these objects which are returned by the find()api (or
some other similar APIs like getChildren()) ,there will be some memory
still held by these object to reference the actual controls in the
application. And it may have its effect on the application during long
executions of scripts.(*Remember that the proxy gets loaded into the AUT
process and hence using the memory allocated to the AUT process )
Conclusion
So
the conclusion is that RFT gives user the capability to do a custom
search/find for the required object along with a Recorder that
generates the script and object map automatically.
A test-script very well could be a combination of hand-coded scripts and the code generated by the recorder.
On
one hand using a recorder is pretty simple and straightforward and may
be sufficient for most of the cases but Handed coded scripts give you
the flexibility to find the objects the way you want(or in situations
where recorder may not be able to detect a control or perhaps playback
engine is not able to find the object the hierarchy and recognition
properties of a mapped test object ) , however it would require you to
have some coding skills (in Java or VB depending on the IDE you are
using).
And last but important point to note is that when
using the dynamic scripting the onus of freeing the objects found by
the find() api is with the user. Releasing object is as simple as just
adding a call to "unregisterAll() " (or other variants) once done with
using the object.
The playback engine does this thing automatically
when the object is a mapped test object thus explicit release of
objects is not required when using traditional record and playback.
Reference : ibm.com/developers
