Coding Standards and Best Practices for "appobjects" Files

 1. Each test object getter in an appobjects class file should be properly commented with javadoc.

Tip: You can easily add javadoc to your code by placing the cursor on the top line of the method you want to javadoc and type /**<enter>. RFT will create a javadoc outline for you including parameters.

 

Standard appobject getter javadoc header (section in light blue text below):

/**
  * @return WButton for OK button in Add Folder page
  */

 public WButton getButton_OK() {

...

 }

 

The appobject class file should also have a javadoc header above the class statement that provides the name of the appobjects class file and describes what the class file is (see below):

/**
 * Class Name   : <b>Browser</b> <BR>
 * Generated     : Oct 1, 2003 4:26:21 PM <BR>
 * Description   : Web Browser Test Object Library <BR>
 * Original Host : WinNT Version 5.0  Build 2195 (Service Pack 4) <BR>
 *
 * @since  2007/10/01 <BR>
 * @author *<BR>
 */

public class Browser extends BrowserHelper
{

...

2. All appobject getters should use a ObjectGetter class wrapper:

There are several getter wrappers in the ObjectGetter class. One for almost every situation. If your situation is a rare special case that a standard wrapper will not work then you can create a custom object getter in your appobject file but this should only be used in special cases. Using the standard getters makes it easy to make global changes to all test objects by only having to modify code in one place. It also makes it easier to manage large projects with lots of test objects. Below is an example of a appobject getter method using a standard ObjectGetter class wrapper. Almost all appobject getters should like this:

 public WButton getButton_Cancel()
 {
  try{return new WButton(og.getNthObject(0,Webfuncs.gsTitleProp, new RegularExpression(".*Cancel.*", false), Webfuncs.gsClassProp, Webfuncs.gsHtmlBtnRef));}catch(Exception e){return null;}   
 }

3.  All appobject getter names should follow the following format:

get<class_type>_<DescriptiveObjectName>() where <class_type> is equal to one of the following:
 
WTextField = Text
WButton = Button
WListBox = List
WLink = Link
WCheckBox = CheckBox
WRadioButton = RadioButton
WTable = Table

 

There may be some special cases that do fall under one of these classtypes but these types should cover approximately 90% to 95% of all test object classes.

 

The <DescriptiveObjectName> should be a descriptive object name in "Proper" case format (each word in the descriptive object name is capitalized for easier identification i.e. MyDescriptiveObject).

 

For example, if I were naming the getter for the "Teamspace Name" text field object it would like this:

getText_TeamSpaceName()

 

4. appobject class files should have a unique name beginning with a capital letter (i.e. Applications.java)

The appobjects automation directory and any of it's subdirectories should be in all lower case characters (i.e. appobjects.administration.admin_console.users) but the appobjects class file name should begin with a capital letter.

 

5. All appobject class files should eventually contain unit tests.

You can easily add unit tests to your appobject file by running the unittest.UnitTestMain script on your appobjects class file.

1. For every appobject class file (i.e. SearchPage, Teamspace, etc. ) for which you want a unit test generated, make an entry in the UnitTestMain script's vector using "v.add" (i.e. v.add(new Teamspace());   )
2. Add import statements as necessary.
3. Check out your appobjects files if they are under source control.
4. Then execute the UnitTestMain script.

The UnitTestMain script will generate a unit test section in your script that looks like the following:

 

 public void testMain (Object[] args)
 {
  og.verifyGetter(getButton_Cancel(), "getButton_Cancel()");
  og.verifyGetter(getButton_OK(), "getButton_OK()");
  }

  

The unit test, when executed, will verify that all of the test objects in your appobjects class file exist on the current browser page and are identifiable by the automation.

 

6. Generally, all necessary external classes are instantiated at the top of an appobjects class file directly below the class statement.

See the placement of the Browser b = new Browser(); statement below. If all of our class files use this area of the script to instantiate other classes it will be easier to find object reference variables, etc.

 

7. As a rule the appobjects folder should contain only test object library files. These test object library files should contain only test object getter methods. The getter methods should do nothing but return an object.

 

8. appobject class files (or tasks files) should not reference/import testcases files.

 

appobjects and tasks files should never reference (import) testcases files. testcases files (Scripts) can and should import the necessary tasks and appobjects files but not vice-versa. A tasks or appobjects file that imports a testcases file will cause a compile error when removing the imported testcases file from the datastore. tasks and appobjects files should never import testcases files.