Advanced Scripting with IBM? Rational? Functional Tester
Advanced Scripting with IBM? Rational? Functional Tester
This module will cover some advanced scripting topics in Rational Functional Tester.
Agenda
Agenda Course Content Overview Understanding TestObjects in Rational Functional Tester Custom Object Finding Techniques Rational Functional Tester Script Hierarchy Remote Method Invocation
By the end of this module, you should understand TestObjects in Rational Functional Tester, custom object finding techniques, script hierarchy, and remote method invocation.
What is a TestObject?
What is a TestObject? A TestObject represents a connection point between a Rational Functional Tester script and the Software Under Test (SUT). Most methods called on a TestObject are invoked in the SUT Two categories of TestObjects: Mapped Bound (?found?, ?pinned?, ?registered?) Rational Functional Tester Script Internet Explorer BrowserTestObject ShDocVw::IWebBrowser Process Boundary
A TestObject represents a connection point between a Rational Functional Tester script and the Software Under Test, or SUT. Most methods called on a TestObject are invoked in the Software Under Test. There are two categories of TestObjects: Mapped and Bound (also known as ?found?, ?pinned?, or ?registered?)
Mapped TestObjects
Mapped TestObjects A Mapped TestObject contains the information necessary to locate a live object in the SUT (Software Under Test) Recognition Properties Hierarchy In your script: button().click() The button is found using the properties from the map The code binds to an object representing the button in the SUT The object can be queried for information The object on the screen is clicked The bound object is freed
A Mapped TestObject contains the information necessary to locate a live object in the Software Under Test. Recognition Properties are different properties of the TestObject being recognized by Rational Functional Tester. The TestObject Hierarchy lists all test objects in the SUT and provides information on owner/owned relationships, states, test domains, and others. In your script: button().click(), the button is found using the properties from the map, and then bound to an object representing the button in the software under test. Next, object is queried for pertinent information, like screen coordinates, and so on. The object on the screen is clicked, and finally, the bound object is freed.
Mapped TestObjects (cont.)
Mapped TestObjects (cont.) The object in the SUT is found every time a Mapped TestObject is used button().click(); button().click(); In this case the object is found twice; once for each click It is implemented in this fashion so that objects are not ?tied up? in the SUT Calling find() on a Mapped TestObject returns a Bound TestObject The object is pinned in the SUT when it is located GuiTestObject buttonTO = button().find(); buttonTO.click(); buttonTO.click(); buttonTO.unregister(); In this case the object is found once and is pinned in the SUT?s memory. Calling unregister() frees up the object in the SUT
The object in the Software Under Test is found every time a Mapped TestObject is used. In this example, the object is found twice; once for each click. Objects are implemented in this fashion so that they are not ?tied up? in the software under test. Second, calling find() on a Mapped TestObject returns a Bound TestObject. The object is pinned in the Software Under Test when it is located. In this example, the object is found once and is pinned in the memory of the software under test. Finally, calling unregister() frees up the object in the software under test.
Bound TestObjects
Bound TestObjects Big difference: Mapped TestObjects are automatically unregistered, Bound TestObjects are not! Methods that return Bound TestObjects: getChildren(), getMappableChildren(), getOwned(), getParent(), getMappableParent(), getOwner(), find(), getTopParent() Use instanceof (Java?) or is (VB.NET), if it is a TestObject then you need to call unregister. Always remember to unregister a TestObject as soon as you are done with it.
When working with Bound TestObjects, there is a big difference between Mapped TestObjects and Bound TestObjects. Mapped TestObjects are automatically unregistered, while Bound TestObjects are not. The methods shown here are used to return Bound TestObjects. As a hint, use the ?instanceof? or ?is? methods if it is a TestObject that you will eventually need to call unregister. Always remember to unregister a TestObject as soon as you are done with it; remember, you are dealing with live objects.
Bound TestObjects (cont.)
Bound TestObjects (cont.) Some scripting hints: Be careful about program flow! Be careful about exceptions. It is best to put your call to unregister in a finally block. TestObject TO = mappedObject.find(); try { // what if the property does not exist? TO.getProperty(?prop?); } finally { TO.unregister(); }
The example shows you how to unregister the bound object. It is helpful to put your call to unregister in a finally block as shown here.
Bound TestObjects (cont.)
Bound TestObjects (cont.) Some scripting hints: A great tip for arrays is to null out the object you are interested in and call unregister on the whole array. TestObject[] allResults = null; TestObject myResult = null; try { allResults = MTO.getChildren(); theGoodResult = allResults[0]; allResults[0] = null; } finally { unregister(allResults); }
Another scripting hint, when working with arrays, is to null out the object you are interested in and to call unregister on the whole array. In the example shown here, the unregister call unregisters the whole array through unregister(allResults);
Custom object finding techniques
Custom object finding techniques The ?old way? The ?new way?: start.find( atDescendant(propName, propVal));
The old way shown here invokes getChildren() and getProperties() multiple times, whereas, the new way invokes find() methods with the result of atDescendant method as a parameter instead. There are some advantages of the find() API as opposed to a recursive search. It is: 1) Much faster - Every call to getChildren() and getProperty() goes cross process. find() goes cross process once, does the entire search, and returns, 2) Much safer - Very easy to leak registered objects in a custom search implementation, and 3) Much easier - find() syntax may be a little tricky at first but it is much easier than writing all the support code for custom solutions
Custom object finding techniques
Custom object finding techniques Two places to start the search: The RootTestObject The RootTestObject is the ?world view? of the system. All domains will be searched. RootTestObject root = getRootTestObject(); Any GUI TestObject, mapped or bound Narrows down the focus of the search. Less likely to get unexpected results. The more you narrow the search, the faster it will run at playback time.
You can start the search from the root or from a specific GUI TestObject. The second option is preferred because it narrows down the focus of the search, is less likely to get unexpected results, and will run faster at playback time.
Custom object finding techniques
Custom object finding techniques Two main syntax concepts: Relationship Direct child Descendant Properties Name/Value pairs Same as properties in Object Map, getProperties(), and properties VPs.
There is a relationships concept and a properties concept. In the relationships concept, there could be a direct child relationship or a descendant relationship. Properties are the name/value pairs. The following slides will go into more details about each of these.
Custom object finding techniques
Custom object finding techniques Relationships atChild() Will only search direct children of the starting point atDescendant() Will search all descendants of the starting point atList() Used to link relationships together Searches are performed in order Express complicated relationships
In the relationship concept, the atChild() will only search direct children of the starting point, the atDescendant() will search all descendants of the starting point, and the atList() will be used to link relationships together. In addition, searches are performed in order, with each successive search starting from the result of the previous search, and can express complicated relationships like ?find a dialog that is a child of a browser and get me any OK button in that dialog? in one API call.
Custom object finding techniques
Custom object finding techniques Properties Matching is all or nothing! No fuzzy matching as seen with Script Assure in location of mapped TestObjects. Make sure you use the correct type. A caption in a Windows? application (.text property) is NOT a String? it is a CaptionText. atChild and atDescendant can take: One name/value pair: atChild(?name?, value); Two name/value pairs: atChild(?name?, value, ?foo?, bar); An array of properties: Property[] props = new Property[] { atProperty(?foo?,bar) }; atChild(props);
As for the properties, keep in mind that matching is all or nothing. Unlike ScriptAssure, you cannot use fuzzy matching. In addition, ensure you use the correct type as shown in the examples here.
Custom object finding techniques
Custom object finding techniques Special Properties .domain Limit the search to a particular test domain Current Domains are: Java, HTML, Win, NET .processName Limit the search to a particular process If you are testing Win32 or .NET controls then the application will also be enabled for testing You should use ?good? recognition properties 100 weight or uniquely identifying properties or both You should constrain the ?search space? Use domain or process information Start the search from an already-found TestObject getRootTestObject().find(atDescendant()) can be a bad idea!
Finally, there are special properties. The .domain and the .processName properties. The .domain property limits the search to a particular test domain. And the .processName property limits the search to a particular process. You should use ?good? recognition properties and constrain the ?search space?
Script class hierarchy
Script class hierarchy TestScript TestScriptHelper HelperSuperclass RationalTestScript (SubitemFactory) Optional Auto generated
TestScript is the class that you primarily interact with. Helper is automatically generated by Rational Functional Tester based on Mapped Test Objects referenced by the script. Helper super class is optional, added at creation if preference set, and is modifiable in script properties. RationalTestScript is the base class for all scripts. The Helper super class MUST extend this class in the end and may have multiple levels in the helper super class inheritance hierarchy as long as RationalTestScript is at the root.
Script class hierarchy (cont.)
Script class hierarchy (cont.) HelperSuperclassA RationalTestScript (SubitemFactory) TestScript1 TestScript1Helper Optional Auto generated TestScript3 TestScript3Helper TestScript2 TestScript2Helper HelperSuperclassB
In an expanded hierarchy, the same inheritance hierarchy apply here. Multiple scripts can be extended using the same helper super class as shown here.
Helper Superclass uses
Helper Superclass uses RationalTestScript method overriding Event handlers Monitor script actions like startApp, callScript, logging, etc Utility methods showMethodInfo doMySpecialVp etc Event handlers onInitialize onTerminate onAmbiguousRecognition onObjectNotFound onRecognitionWarning onSubitemNotFound onCallScriptException onTestObjectMethodException onUnhandledException onVpFailure
You can override the following methods in order to customize your application. There are also some utility methods you can invoke like the showMethodinfo and doMySpecialVP. Event handlers allow you to have your own implementation when certain events occur.
Advanced example: ?Last Chance? find
Advanced example: ?Last Chance? find The Problem: The GUI hierarchy in the application you are testing sometimes changes Script Assure requires rigid hierarchy Concepts Applied: find() using properties OnObjectNotFound() exception handler Programmatic access of Mapped TestObjects Using TestObjectMethodState
This advanced example explores the ?last chance? find. The problem: The GUI hierarchy in the application you are testing sometimes changes, and Script Assure requires rigid hierarchy.
Advanced example: ?Last chance? find
Advanced example: ?Last chance? find The Solution: Override the OnObjectNotFound() exception handler Gain access to the recognition properties of the Mapped TestObject you were trying to interact with Use find() to try and locate the object without hierarchy constraints If more than one result, throw an AmbiguousRecognitionException or pick one of the results (danger: ?gliding?) If no results found, continue with ObjectNotFoundException If one result, set the found object in the TestObjectMethodState
The solution: you should override the OnObjectNotFound() exception handler and gain access to the recognition properties of the Mapped TestObject you were trying to interact with. You can also use find() to try and locate the object without hierarchy constraints.
Remote method invocation
Remote method invocation Run methods on an object in the SUT using: invoke() findAndInvoke() do a ?find? with properties and invoke the specified method provided one object is found What it is good for: Objects in the SUT for which Rational Functional Tester does not have a proxy For example, a custom JFC Spinner control Additional non-GUI-related testing that cannot be accessed using properties Querying ClearCase? source control information in the IDE you are developing
Remote Method Invocation is used by invoking the Software Under Test?s own method from Rational Functional Tester. It calls methods on an object in the Software Under Test through the invoke() and findAndInvoke() methods. Remote method invocation is beneficial in some scenarios such as when objects in the SUT for which Rational Functional Tester does not have a proxy and for non-GUI-related testing that cannot be accessed through the properties controls.
Remote method invocation
Remote method invocation When invoking methods that take arguments, the method signature needs to be passed to invoke. The method signature uses JNI (Java Native Interface) syntax The Test Object Inspector is your best friend!
When invoking methods that take arguments, the method signature needs to be passed to invoke. The method signature uses Java Native Interface syntax. Use the Test Object Inspector to view method information as shown here.
Remote method invocation
Remote method invocation
Shown here is an example of the list of the methods and JNI parameters from the Test Object Inspector.
Remote method invocation
Remote method invocation Object[] invokeArgs = new Object[]{new Boolean(true)}; reorderingAllowed().invoke( "setBorderPaintedFlat", "(Z)V", invokeArgs);
The example shown here shows you how to call the invoke() method with the correct parameters.
Remote method invocation
Remote method invocation You can modify the software in ways that a user cannot Discuss the methods being invoked with the development team, if possible Be careful of the return value of the invoke? if there is no value class then a TestObject will be returned Do not forget to unregister the returned TestObject!
When using Remote Method Invocation, be aware that you can modify the software in ways that a user can not. You should discuss the methods being invoked with the development team. Be careful of the return value of the invoke? if there is no value class, then a TestObject will be returned, and finally, do not forget to unregister the returned TestObject!
Summary
Summary Advanced overview of Rational Functional Tester Scripting, including: Understanding TestObjects in Rational Functional Tester Custom Object Finding Techniques Rational Functional Tester Script Hierarchy Remote Method Invocation
In summary, you should now have a working knowledge of advanced scripting functions in Rational Functional Tester, including: TestObjects in Rational Functional Tester, Custom Object Finding Techniques, Rational Functional Tester Script Hierarchy, and Remote Method Invocation. For more information on these topics, reference the Rational Functional Tester API on the online help.
Trademarks
Advanced Scripting with IBM® Rational® Functional Tester
Advanced Scripting with IBM® Rational® Functional Tester
This module will cover some advanced scripting topics in Rational Functional Tester.
Agenda
Agenda Course Content Overview Understanding TestObjects in Rational Functional Tester Custom Object Finding Techniques Rational Functional Tester Script Hierarchy Remote Method Invocation
By the end of this module, you should understand TestObjects in Rational Functional Tester, custom object finding techniques, script hierarchy, and remote method invocation.
What is a TestObject?
What is a TestObject? A TestObject represents a connection point between a Rational Functional Tester script and the Software Under Test (SUT). Most methods called on a TestObject are invoked in the SUT Two categories of TestObjects: Mapped Bound (“found”, “pinned”, “registered”) Rational Functional Tester Script Internet Explorer BrowserTestObject ShDocVw::IWebBrowser Process Boundary
A TestObject represents a connection point between a Rational Functional Tester script and the Software Under Test, or SUT. Most methods called on a TestObject are invoked in the Software Under Test. There are two categories of TestObjects: Mapped and Bound (also known as “found”, “pinned”, or “registered”)
Mapped TestObjects
Mapped TestObjects A Mapped TestObject contains the information necessary to locate a live object in the SUT (Software Under Test) Recognition Properties Hierarchy In your script: button().click() The button is found using the properties from the map The code binds to an object representing the button in the SUT The object can be queried for information The object on the screen is clicked The bound object is freed
A Mapped TestObject contains the information necessary to locate a live object in the Software Under Test. Recognition Properties are different properties of the TestObject being recognized by Rational Functional Tester. The TestObject Hierarchy lists all test objects in the SUT and provides information on owner/owned relationships, states, test domains, and others. In your script: button().click(), the button is found using the properties from the map, and then bound to an object representing the button in the software under test. Next, object is queried for pertinent information, like screen coordinates, and so on. The object on the screen is clicked, and finally, the bound object is freed.
Mapped TestObjects (cont.)
Mapped TestObjects (cont.) The object in the SUT is found every time a Mapped TestObject is used button().click(); button().click(); In this case the object is found twice; once for each click It is implemented in this fashion so that objects are not “tied up” in the SUT Calling find() on a Mapped TestObject returns a Bound TestObject The object is pinned in the SUT when it is located GuiTestObject buttonTO = button().find(); buttonTO.click(); buttonTO.click(); buttonTO.unregister(); In this case the object is found once and is pinned in the SUT’s memory. Calling unregister() frees up the object in the SUT
The object in the Software Under Test is found every time a Mapped TestObject is used. In this example, the object is found twice; once for each click. Objects are implemented in this fashion so that they are not “tied up” in the software under test. Second, calling find() on a Mapped TestObject returns a Bound TestObject. The object is pinned in the Software Under Test when it is located. In this example, the object is found once and is pinned in the memory of the software under test. Finally, calling unregister() frees up the object in the software under test.
Bound TestObjects
Bound TestObjects Big difference: Mapped TestObjects are automatically unregistered, Bound TestObjects are not! Methods that return Bound TestObjects: getChildren(), getMappableChildren(), getOwned(), getParent(), getMappableParent(), getOwner(), find(), getTopParent() Use instanceof (Java™) or is (VB.NET), if it is a TestObject then you need to call unregister. Always remember to unregister a TestObject as soon as you are done with it.
When working with Bound TestObjects, there is a big difference between Mapped TestObjects and Bound TestObjects. Mapped TestObjects are automatically unregistered, while Bound TestObjects are not. The methods shown here are used to return Bound TestObjects. As a hint, use the “instanceof” or “is” methods if it is a TestObject that you will eventually need to call unregister. Always remember to unregister a TestObject as soon as you are done with it; remember, you are dealing with live objects.
Bound TestObjects (cont.)
Bound TestObjects (cont.) Some scripting hints: Be careful about program flow! Be careful about exceptions. It is best to put your call to unregister in a finally block. TestObject TO = mappedObject.find(); try { // what if the property does not exist? TO.getProperty(“prop”); } finally { TO.unregister(); }
The example shows you how to unregister the bound object. It is helpful to put your call to unregister in a finally block as shown here.
Bound TestObjects (cont.)
Bound TestObjects (cont.) Some scripting hints: A great tip for arrays is to null out the object you are interested in and call unregister on the whole array. TestObject[] allResults = null; TestObject myResult = null; try { allResults = MTO.getChildren(); theGoodResult = allResults[0]; allResults[0] = null; } finally { unregister(allResults); }
Another scripting hint, when working with arrays, is to null out the object you are interested in and to call unregister on the whole array. In the example shown here, the unregister call unregisters the whole array through unregister(allResults);
Custom object finding techniques
Custom object finding techniques The “old way” The “new way”: start.find( atDescendant(propName, propVal));
The old way shown here invokes getChildren() and getProperties() multiple times, whereas, the new way invokes find() methods with the result of atDescendant method as a parameter instead. There are some advantages of the find() API as opposed to a recursive search. It is: 1) Much faster - Every call to getChildren() and getProperty() goes cross process. find() goes cross process once, does the entire search, and returns, 2) Much safer - Very easy to leak registered objects in a custom search implementation, and 3) Much easier - find() syntax may be a little tricky at first but it is much easier than writing all the support code for custom solutions
Custom object finding techniques
Custom object finding techniques Two places to start the search: The RootTestObject The RootTestObject is the “world view” of the system. All domains will be searched. RootTestObject root = getRootTestObject(); Any GUI TestObject, mapped or bound Narrows down the focus of the search. Less likely to get unexpected results. The more you narrow the search, the faster it will run at playback time.
You can start the search from the root or from a specific GUI TestObject. The second option is preferred because it narrows down the focus of the search, is less likely to get unexpected results, and will run faster at playback time.
Custom object finding techniques
Custom object finding techniques Two main syntax concepts: Relationship Direct child Descendant Properties Name/Value pairs Same as properties in Object Map, getProperties(), and properties VPs.
There is a relationships concept and a properties concept. In the relationships concept, there could be a direct child relationship or a descendant relationship. Properties are the name/value pairs. The following slides will go into more details about each of these.
Custom object finding techniques
Custom object finding techniques Relationships atChild() Will only search direct children of the starting point atDescendant() Will search all descendants of the starting point atList() Used to link relationships together Searches are performed in order Express complicated relationships
In the relationship concept, the atChild() will only search direct children of the starting point, the atDescendant() will search all descendants of the starting point, and the atList() will be used to link relationships together. In addition, searches are performed in order, with each successive search starting from the result of the previous search, and can express complicated relationships like “find a dialog that is a child of a browser and get me any OK button in that dialog” in one API call.
Custom object finding techniques
Custom object finding techniques Properties Matching is all or nothing! No fuzzy matching as seen with Script Assure in location of mapped TestObjects. Make sure you use the correct type. A caption in a Windows® application (.text property) is NOT a String… it is a CaptionText. atChild and atDescendant can take: One name/value pair: atChild(“name”, value); Two name/value pairs: atChild(“name”, value, “foo”, bar); An array of properties: Property[] props = new Property[] { atProperty(“foo”,bar) }; atChild(props);
As for the properties, keep in mind that matching is all or nothing. Unlike ScriptAssure, you cannot use fuzzy matching. In addition, ensure you use the correct type as shown in the examples here.
Custom object finding techniques
Custom object finding techniques Special Properties .domain Limit the search to a particular test domain Current Domains are: Java, HTML, Win, NET .processName Limit the search to a particular process If you are testing Win32 or .NET controls then the application will also be enabled for testing You should use “good” recognition properties 100 weight or uniquely identifying properties or both You should constrain the “search space” Use domain or process information Start the search from an already-found TestObject getRootTestObject().find(atDescendant()) can be a bad idea!
Finally, there are special properties. The .domain and the .processName properties. The .domain property limits the search to a particular test domain. And the .processName property limits the search to a particular process. You should use “good” recognition properties and constrain the “search space”
Script class hierarchy
Script class hierarchy TestScript TestScriptHelper HelperSuperclass RationalTestScript (SubitemFactory) Optional Auto generated
TestScript is the class that you primarily interact with. Helper is automatically generated by Rational Functional Tester based on Mapped Test Objects referenced by the script. Helper super class is optional, added at creation if preference set, and is modifiable in script properties. RationalTestScript is the base class for all scripts. The Helper super class MUST extend this class in the end and may have multiple levels in the helper super class inheritance hierarchy as long as RationalTestScript is at the root.
Script class hierarchy (cont.)
Script class hierarchy (cont.) HelperSuperclassA RationalTestScript (SubitemFactory) TestScript1 TestScript1Helper Optional Auto generated TestScript3 TestScript3Helper TestScript2 TestScript2Helper HelperSuperclassB
In an expanded hierarchy, the same inheritance hierarchy apply here. Multiple scripts can be extended using the same helper super class as shown here.
Helper Superclass uses
Helper Superclass uses RationalTestScript method overriding Event handlers Monitor script actions like startApp, callScript, logging, etc Utility methods showMethodInfo doMySpecialVp etc Event handlers onInitialize onTerminate onAmbiguousRecognition onObjectNotFound onRecognitionWarning onSubitemNotFound onCallScriptException onTestObjectMethodException onUnhandledException onVpFailure
You can override the following methods in order to customize your application. There are also some utility methods you can invoke like the showMethodinfo and doMySpecialVP. Event handlers allow you to have your own implementation when certain events occur.
Advanced example: “Last Chance” find
Advanced example: “Last Chance” find The Problem: The GUI hierarchy in the application you are testing sometimes changes Script Assure requires rigid hierarchy Concepts Applied: find() using properties OnObjectNotFound() exception handler Programmatic access of Mapped TestObjects Using TestObjectMethodState
This advanced example explores the ‘last chance’ find. The problem: The GUI hierarchy in the application you are testing sometimes changes, and Script Assure requires rigid hierarchy.
Advanced example: “Last chance” find
Advanced example: “Last chance” find The Solution: Override the OnObjectNotFound() exception handler Gain access to the recognition properties of the Mapped TestObject you were trying to interact with Use find() to try and locate the object without hierarchy constraints If more than one result, throw an AmbiguousRecognitionException or pick one of the results (danger: “gliding”) If no results found, continue with ObjectNotFoundException If one result, set the found object in the TestObjectMethodState
The solution: you should override the OnObjectNotFound() exception handler and gain access to the recognition properties of the Mapped TestObject you were trying to interact with. You can also use find() to try and locate the object without hierarchy constraints.
Remote method invocation
Remote method invocation Run methods on an object in the SUT using: invoke() findAndInvoke() do a “find” with properties and invoke the specified method provided one object is found What it is good for: Objects in the SUT for which Rational Functional Tester does not have a proxy For example, a custom JFC Spinner control Additional non-GUI-related testing that cannot be accessed using properties Querying ClearCase® source control information in the IDE you are developing
Remote Method Invocation is used by invoking the Software Under Test’s own method from Rational Functional Tester. It calls methods on an object in the Software Under Test through the invoke() and findAndInvoke() methods. Remote method invocation is beneficial in some scenarios such as when objects in the SUT for which Rational Functional Tester does not have a proxy and for non-GUI-related testing that cannot be accessed through the properties controls.
Remote method invocation
Remote method invocation When invoking methods that take arguments, the method signature needs to be passed to invoke. The method signature uses JNI (Java Native Interface) syntax The Test Object Inspector is your best friend!
When invoking methods that take arguments, the method signature needs to be passed to invoke. The method signature uses Java Native Interface syntax. Use the Test Object Inspector to view method information as shown here.
Remote method invocation
Remote method invocation
Shown here is an example of the list of the methods and JNI parameters from the Test Object Inspector.
Remote method invocation
Remote method invocation Object[] invokeArgs = new Object[]{new Boolean(true)}; reorderingAllowed().invoke( "setBorderPaintedFlat", "(Z)V", invokeArgs);
The example shown here shows you how to call the invoke() method with the correct parameters.
Remote method invocation
Remote method invocation You can modify the software in ways that a user cannot Discuss the methods being invoked with the development team, if possible Be careful of the return value of the invoke… if there is no value class then a TestObject will be returned Do not forget to unregister the returned TestObject!
When using Remote Method Invocation, be aware that you can modify the software in ways that a user can not. You should discuss the methods being invoked with the development team. Be careful of the return value of the invoke… if there is no value class, then a TestObject will be returned, and finally, do not forget to unregister the returned TestObject!
Summary
Summary Advanced overview of Rational Functional Tester Scripting, including: Understanding TestObjects in Rational Functional Tester Custom Object Finding Techniques Rational Functional Tester Script Hierarchy Remote Method Invocation
In summary, you should now have a working knowledge of advanced scripting functions in Rational Functional Tester, including: TestObjects in Rational Functional Tester, Custom Object Finding Techniques, Rational Functional Tester Script Hierarchy, and Remote Method Invocation. For more information on these topics, reference the Rational Functional Tester API on the online help.
Trademarks