The most tedious part of creating a test automation framework in Rational Functional Tester (RFT) is mapping the objects that belong to the Application Under Test (AUT). There isn’t too much that can be done to aleviate the pain, your only hope is to make sure that you only have to map those objects once. One aspect of the object map that can be tamed is the naming of the objects. Using a naming standard consistently can increase the maintainability of the object map, so to save you figuring one out, here’s one that’s worked for me in the past.

Note 1: The naming convention is based on the “hierarchical name space” arrangement, similar to the way libraries are organised in java e.g. java.lang.String.
Note 2: The convention also uses “lowerCamelCase” to name the objects. Camel case is the practice of capitalising each word in a phrase, and concatenating the words by removing the spaces. “Lower” camel case is where the first letter of the phrase is changed to a lower case letter. Due to a quirk in RFT’s implementation of object mapping, “UpperCamelCase” is painful to use.
Note 3: No part of the naming standard is mandatory, but I’ve found through experience that the more of the convention is used, the more maintainable the object map is. In frameworks where there is only one object map, using the naming convention in its entirety is strongly advised. If your framework separates object maps by application, part 1 may not be necessary. If you have one object map for each window in your AUT, only the last 2 parts may be necessary.

Part 1
The name of each object begins with the name of the application or something that would identifiy the same. For example, if your AUT is called “Widget”, the name of each object that belongs to that app would begin with widget. Or if your AUT is called “Cheese Factory Management System”, beginning each relevant object with “cfms” would be enough. Beginning each object name with the name of the AUT ensures that they will be sorted correctly in an object map, i.e. all the objects for each AUT will be grouped together.

Part 2
The second section of the object name should define which section of the AUT it is in. The details of this will depend on the application you’re testing. If the AUT is made up of multiple windows, it may be logical to group together the objects that are located in a particular window. If the AUT is made up of one window with activity-related panels, you could use the panel names. If you’re testing a web app, it may be logical to group together all the objects on one page. The AUT in question will be the deciding factor on what this section of the object name will be. A window-based application makes deciding on the name easy; other styles of AUT layout could make this more difficult.

Example 1: Each object in the “Logon” window of the “Widget” AUT could begin with widgetLogon, or msdgfwLogon.
Example 2: Each object in the “Customer Name & Address Details” window of the “Cheese Factory Management System” could begin with cfmsCustNameAddressDetails.

Part 3
Use of the third part of the naming convention is not mandatory, but is useful for mapping a window within the AUT that contains many objects. Objects in windows are usually grouped together based on function. For example, a window containing both Name and Address details may split the relevant objects into separate groups. Deciding on a name for the window area is usually made quite easy when the objects are grouped into a frame; you can just use the name given by the AUT. If the group of objects don’t have a frame that they belong in, a name for the group of them should be carefully chosen. Even without a frame, getting a name for a group of objects can still be easy, e.g. all objects in a tab can use the tab name; objects that define search criteria can use Search, etc…

Example: Each customer name related object in the “Customer Name & Address Details” window of the “Cheese Factory Management System” could begin with cfmsCustNameAddressDetailsName; the customer address related objects could begin with cfmsCustNameAddressDetailsAddress.

Part 4
Now that all objects in an AUT are grouped down to a specific location there remains only the need to differentiate between the objects within windows (part 2), frames or tabs (part 3). The fourth section of the naming standard is used to identify what type of object the mapped object is; e.g. button, label, textfield, menu, window, etc… The following list of object types is given as a guide.

ObjectType	Abbreviation
Button	Btn
CheckBox	Chk
Combo Box	Cmb
Dialog Box	Dlg
Editor Pane	Edp
Label	Lbl
List	Lst
Option Button	Opt
Picture	Pct
Popup Menu	Pop
Scroll Pane	Scr
Tab	Tab
Tabbed Pane	Tpn
Table	Tbl
Table Header	Tbh
Text Field	Txt
Tree	Tre
Window	Wnd

Defining the type of object in the naming convention leads to even more grouping together ob objects in RFT Script explorer. For example, all buttons in a particualr area of a particular window will be grouped together; or if part 3 of the naming convention wasn’t used, all objects of the same type within a window will be grouped together.

Example 1: All text fields in the window area to do with customer names in the “Customer Name & Address Details” window of the “Cheese Factory Management System” could begin with cfmsCustNameAddressDetailsNameTxt; the text fields in the
window area to do with address details could begin with cfmsCustNameAddressDetailsAddressTxt.

Part 5
The last part of the naming convetion is to identify the object itself. This is usually quite easy as GUI objects usually provide a name; e.g. a Save button could be called “Save”! A textfield labelled as “First Name” could be identified as “FirstName”.

Example 1: The text field for the first name of a customer in the “Customer Name & Address Details” window of the “Cheese Factory Management System” could be cfmsCustNameAddressDetailsNameTxtFirstName and the Last Name textfield could be cfmsCustNameAddressDetailsNameTxtLastName.

The naming convention is quite verbose, but it does provide a very maintainable object map. Name collisions are rare (I’ve never encountered any using the above convention), and due to the nature of the way us humans read and sort globs of text, the object names are actually quite readable!