Is it safe to hold on to a mapped TestObject in RFT?

Question

Mapped TestObjects are generally accessed through getter methods, e.g.

button().click();
// Other code
button().click();
// ...
button().click();

Is there any reason why I shouldn't retrieve the TestObject once and reuse it? E.g.

GuiTestObject button = button();
button.click();
button.click();
button.click();

Or, stated differently, is there any reason why RFT generates getter methods instead of member variables?

The only potential reason I can think of would be to avoid tying up the application under test's memory, but that doesn't make any sense to me; Java finalizers aren't reliable so I doubt RFT is freeing up any resources when the TestObject is garbage collected. Plus, the fact that I can keep using the same mapped TestObject even if I close and re-open the application suggests RFT is re-finding (and subsequently unregistering) the test object every time I try to use it.

If there's no downside, why does every reference I find access TestObjects through getter methods exclusively? E.g. An Object-Oriented framework for IBM RFT, listings 2 and 3.

Answer 1

I think, first its because

button().click();  

is cleaner/simpler code to a user than ..

GuiTestObject button = new GuiTestObject( getMappedTestObject("thebutton"));//This currently resides in the helper file.
 button.click();

Second, the button() method can be passed an "Anchor" and a "Flag" also which is again implemented in the Helper class.so again

    button(anchorobject,flags).click();

is simpler than having, one more button object

    GuiTestObject button1 = new GuiTestObject(getMappedTestObject("thebutton"),anchor,flags);
    button1.click(); 

In case you mean having something like..

GuiTestObject button = button();//where button() still is in helper class
button.click();
button.dosomthingelse();

Then we would need to specify the actual type of object for the button then we have a different TestObject type for Text controls and selects and trees etc. With this existing approach the user can be completely unaware of existence of different types of TestObjects (GuiTestObject / TextGuiTestObject/SelectGuiSubitemTestObject) etc which is returned by the getter method of an object.

What we are dealing with in the script is a TestObject which resides in the playback process. TestObject is just a specification to find an actual object in the application and create a proxy for it (which resides in the application process) , and this proxy is what gets released once a particular action completes (click() for instance). However the TestObject is still valid , and as you have rightly said RFT would again find the object if you reuse the testobject. TestObject would be taken care of by the Garbage collector as and when required, user can further optimize that code I guess. Finally to answer your question I am not aware what would be the downside of using the testobject you have. I don't think it will help you in terms of performance also though. Try timing how much time it saves you if any by using an Object instead of the getter , try it on Java application which is statically enabled.