Are there any tips or suggestions for dealing with custom objects?
Taming the Custom Object
by Brian Le Suer, Co-Founder, Star Quality
Not many of us are lucky enough to test an application where all its objects map nicely to standard 4Test controls. There would be no fun in that anyway! More the rule than the exception, custom objects are used in most client-server and Web applications to enhance the standard set of controls: the MenuItems, TextFields, ListBoxes, RadioLists, CheckBoxes and PushButtons that form the backbone of the application"s Graphical User Interface GUI).
Fortunately the 4Test language was designed with custom objects in mind. In fact, SilkTest provides a multitude of support options to the test engineer so that most custom controls can be made to appear fully supported by the 4Test language. We only have to apply the principles described below with a good measure of creativity. The steps outlined in this article can be used to guide the design and development of a test API for most custom objects when simple class mapping won"t do the trick.
Step One: Understand the Object"s Behaviour
The first step in providing testing support for a custom control is to study the way in which the control responds to the keyboard and mouse. Generally, the keyboard provides a more deterministic interface with a control than the mouse. Where applicable, note the sequence of keystrokes that will move the input focus to the top and bottom of the control. For example, in a custom grid or table control, the and keys along with the and keys can be used to move the input focus to the beginning and end of rows and highlight blocks of columns.
The position of the mouse can also be useful. The current X,Y position of the cursor can be obtained by calling the GetPosition() method on the cursor class. With this coordinate, it is possible to calculate a relative offset to implement a click in a hotspot that is not otherwise recognized by SilkTest. This might prove useful, for example, in a TreeView control to set the state of a CheckBox that does not respond to the key. By getting the position of the cursor after a selection has been made, it"s easy to calculate the position of the corresponding CheckBox so that it can be toggled to the desired state.
The clipboard also provides a useful mechanism for ascertaining the state of a custom control. For example, where 4Test might not recognize a row/column in a table, it is usually practical to select the cell via the keyboard and the copy its contents to the clipboard, where a GetText() method can be called to return the result.
Step Two: Design the Object"s Test Interface
When setting out to develop a set of services to interface with a custom control, the ultimate goal should be to make it appear as if the object has native 4Test support. The best way to achieve that end is to model the object"s interface on the standard 4Test class that the object most closely resembles. Using the properties and methods of a 4Test class as a specification for those of the custom object, the requirements can be determined for setting and getting methods along with the types and names of parameters and return values. Be sure to support the same calling prototype as the model method, where possible. The arguments that the method requires were selected with good reason when we built the 4Test methods. Modelling the methods after similar 4Test built-ins not only saves work effort, but it also assures a more consistent interface across all of the application objects. The 4Test Table class is a good example. It provides a rich interface from which to model virtually any table or grid method.
It may not be necessary to support all of the methods that we supply for the control being used as your model. Some may not be applicable to this specific object class, and others may not be needed.
Step Three: Evaluate Available Intrinsic Support
Many custom controls provide an interface that may be accessible from within 4Test. If the object is developed with either Visual Basic or Java, it is likely that SilkTest can record the object"s methods and properties so that they will be directly callable from within user-defined methods. Before attempting to record an object"s class, follow the SilkTest instructions for enabling an extension very carefully. Use the Extension Enabler from the Start menu and from within the product via the Options Menu. Remember to indicate the ActiveX or Java technology from which the object is built in the appropriate CheckBox (never select both of these for a single extension). Even if an attempt to use record class fails, often using CaptureAllClasses or CaptureObjectClass (stored in captureclass.inc), will provide successful results where attempts to record the class have failed.
DLLs provide yet another means of accessing a custom object"s methods and properties. By using the DLL statement to declare a dynamic link library in 4Test and defining its function prototypes, a given function can be called in much the same way as a built-in 4Test function. For example the SendMessage function in user32.dll can be used to input a string to a TextField when SetText and TypeKeys refuse to work. Just get the string onto the clipboard using ClipBoard.SetText("some string") and call SendMessage with the API message WM_Paste as follows:
SendMessage(MyWindow.hWnd, WM_PASTE, 0,0).
This combination will essentially take the contents of the clipboard and paste it into the stubborn TextField. Custom controls will often respond to SendMessage, but this requires the message to send. It may be necessary to consult with the object"s developer to get message names and any parameters that may be required.
Another source of information about a custom object"s behaviour can often be obtained by looking for visual cues in associated objects. For example, a TextField or StatusBar associated with a drawing area may report upon the cursor position and the state of the contents on the canvas. This information can, in turn, be used to manipulate the objects being drawn.
Step Four: Develop the Test API for the Object
An API for a custom object is developed by creating methods and properties that perform setting and getting activities upon the object. The best structure in which to encapsulate these methods and properties is an object class.
To create a new class, use the keyword winclass and provide a name for the new class. Usually a custom object will be derived from the AnyWin class, although not all of the inherited methods and properties will yield useful results. The following is an example of a user defined class declaration:
winclass MyNewClass : AnyWin
After creating the new class, remember to change the class of the all object occurrences from CustomWin to the name of the newly defined class.
The methods and properties that comprise the test API will fulfil the requirements documented in step two and utilize the object heuristics and intrinsics that were discovered through studying the object as described in steps one and three above. The following is an example of a method written to support the OLEGrid.
The GetCellValue method displayed from the MYOLEGrid class is modelled after the GetCellValue from the 4Test Table class in that it takes a TABLECELL and returns a string. It uses native properties and methods of the OLEGrid class to determine the layout of the grid so that it can select the desired cell. Then it uses the native property sClip to return the text of that cell. In like fashion, it is possible to write FindCell, SetCellValue and other table methods on this and most other custom grids.
Step Five : Document API
Finally the Test API must be documented so that the project team can gain an understanding about its support and usage requirements. The SilkTest Library Browser will automatically display basic information about the new object class and its methods and properties. SilkTest also provides the ability to enhance this documentation by allowing the API developer to update the 4Test.txt file stored in the directory where SilkTest is installed. The API developer should also provide a Help page for each of the provided methods and properties using the 4Test Reference in the SilkTest Online Help as a model.
With SilkTest, a custom object need not be a roadblock to building effective test automation. Instead it provides an interesting challenge to sharpen the skills of the test automation engineer.
About the Author
Brian Le Suer is a cofounder of Star Quality (www.automatedtesting.com), a New England-based firm specializing in consulting and training for Software Quality Assurance and Test Automation. Star Quality provides test APIs for third party and custom controls. Prior to founding Star Quality, Brian held several senior management positions with Segue in the areas of QA, training and consulting, and product development.
Readers may contact Brian at: email@example.com.