FAQ

Everything you need to know about custom objects in SilkTest.

Detail

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 Graphical User Interface.

Fortunately 4Test was designed with custom objects in mind. In fact, SilkTest provides a multitude of support 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 following steps can be used to guide the design and development of a Test API for most custom objects:

Step One: Understand the object’s behavior

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 <HOME> and <END> keys along with the <SHIFT> and <CTRL> 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 xy position of the cursor can be obtained by calling the GetPosition() method on the cursor class. With this coordinate, it is possible 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 <SPACE> 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, your 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, you can determine the requirements for setting and getting methods along with the types and names of parameters and return values. This 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 are rich interface from which to model virtually any table or grid method.

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. You must 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. Even if an attempt to use record class fails, don’t give up. Often using CaptureAllClasses or CaptureObjectClass (stored in captureclass.inc), will provide successful results where attempts to record the class had 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 function in a dll can be called in much the same way as a built-in 4Test function. For example the SendMessage function can be used to …

Another source of information about custom object behavior 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 fulfill 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.

Step Five: Test the API

The API developed for a custom object should be as robust as the built-in support that 4Test provides for standard GUI objects. Before it is deployed for usage in a test automation project, the Test API needs to be thoroughly tested. To ensure the methods and properties will respond properly in all situations, develop a test plan for the Test API in the same way that you would for a feature in the application under test. Automate both positive and negative tests. Fix the inevitable bugs and rerun the tests until you are satisfied with the results. Be sure to keep the tests for later use when enhancements are implemented in future releases.

Step Six: 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.inc 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 sharper the skills of the test automation engineer.