Category Archives: Test Management

How to know your ruby Test::Unit test result

Posted on by
Reply

If a test passes, you usually don’t want to know any more – nothing to see here, move along. But, if a test fails or errors, you become far more interested. But… how to know if a test failed or not? If you could tell, you could do useful things like taking screenshots, writing stack traces to a file, etc. So it’d be useful to know the result.

Using ruby’s Test::Unit, it’s easy. Since test cases inherit from Test::Unit::TestCase, and since Test::Unit::TestCase contains an instance variable called @test_passed – a boolean, you can access the result  of your test with no problem. So the following is possible:


class MyTests < Test::Unit::TestCase
  def setup
    #do nothing
  end
  def teardown
    if @test_passed then
      puts "Yay! The test passed!"
    else
      puts "Oh no! The test went bad!"
    end
  end
  def test_that_passes
    assert(true)
  end
  def test_that_fails
    assert(false)
  end
end

See the code in the teardown? It’s doing stuff based on the test result. I’m sure you can come up with a better use for this than printing silly strings…

Example Naming Standard for Mapped AUT Objects

Posted on by
Reply

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!