Testing CustomWins with SilkTest

Introduction

An object is defined by:

Its actual class name The underlying software code that creates and manipulates it

SilkTest defines an object (window or control) as a CustomWin whenever that object does not correspond to a Silktest native definition. While you are Recording Window Declarations, SilkTest attempts to identify the class of each object in your GUI and assign the appropriate class from the built-in class hierarchy. SilkTest supports the standard MFC (Microsoft Foundation Class) library which contains functions that allow for the creation of objects and the creation of the methods of interaction with them. In supporting these libraries, SilkTest contains algorithms to interrogate the objects based upon the standard libraries. When these algorithms do not work, SilkTest reports the object as a CustomWin.

Derivation of a CustomWin

The SilkTest help files have this to say about the derivation of the CustomWin class:-

DescriptionCustomWin is the class for objects that do not map to or derive from any built-in classes.

InheritanceCustomWin is derived from the AnyWin class; no classes derive from this class.

MethodsCustomWin inherits all its methods from the AnyWin class.

PropertiesCustomWin inherits all its properties from the AnyWin class.

For reference, the derivation of the AnyWin class is reproduced here:-

AnyWin classAnyWin is the class for any window.

In SilkTest the word "window" is used very generally to refer to any object or widget in a GUI. All classes derive from AnyWin; therefore, a pushbutton, scroll bar, and check box are all considered windows, as are dialogs, menus, and menu items.

There are two main reasons why SilkTest sees an object as a CustomWin.

Upon its definition in the application under test, the control was simply named differently than the standard name. For example, instead of it being named a TextField, it was named EnterTextRegion. If this is the only reason, then you can class map the control to the standard name and be able to interact with it using all of the TextField methods.

The object truly is a custom object; that is, the software in the application under test that creates and manipulates the object is not from the standard library. That means that the SilkTest algorithms written to interrogate this kind of object will not work, and other approaches will have to be used to manipulate the object.

Classmapping

Classmapping should always be the first attempt to recognise a CustomWin. The downside is you will not know whether class mapping will work until you try it. The following steps illustrate classmapping the RichEdit control in WordPad to a normal TextField control. While Recording Window Declarations perform the following steps:

1. Press Ctrl+Alt. The declarations are frozen in the Window Declaration list box in the lower half of the Record Window Declarations dialog.

2. In the Window Declarations list box, click on the line containing the declaration for the custom object. The line is highlighted and the declaration for the CustomWin appears in the Window Detail group box.

3. In the Window Detail group box, press the Class Map pushbutton. The Class Map dialog appears. The name of the custom class is displayed in the Custom Class text field. In the Standard Class field, use the combobox to select the name of the built-in 4Test class to which you are mapping the custom class.

4. Click Add and then click OK.

When you resume recording, the object has the standard 4Test class. Any subsequent similar objects encountered will automatically be mapped to the correct 4Test class.

Classmapping will only work if the object is a simple, single object such as a TextField. If an application contains a graphical area, for example, a tool bar which is actually composed of a discrete number of graphical objects, SilkTest records a single declaration for the entire graphical area because it does not understand that the area contains individual objects. There are other low-level methods which can be utilised to deal with this situation.

DLL Calling

In some cases the object also has supporting .dlls which it requires to function correctly. It may be possible to manipulate the custom object indirectly by calling these supporting .dlls. This requires that the SilkTest coder knows the prototype calls that are available in the public area of the .dll. Dll calls will only work for Win32 applications as dotNet applications do not have a publically exposed ExportTable. An extensive FAQ on using dll calls with examples can be found here.

Dll calls can also be used to override the inbuilt SilkTest methods for some objects by using the SendMessage WinAPI call. An example of how to override the existing GetText() and SetText() methods can be found here.

Note: You can call dll functions from 4Test scripts, but you cannot call member functions in a dll. SilkTest is also not able to deal with pointers as it is a scripting language and not a programming language.

CaptureAllClasses()

The CaptureAllClasses() function records the public class information of a specified Java object or ActiveX object and of the object's children. Using this function you can record the methods and properties of multiple classes from a script instead of using the recorder. The class information is stored in the results file produced by the test run. With this approach, you can record a large number of classes using one function call, rather than having to record each class individually. The information returned will have been set public by the application’s creator, but there is no guarantee that SilkTest will be able to use any or all of this information. Please be aware also that depending on the size of the application, it may take SilkTest many minutes to discover and return all public information.

There is a manual equivalent of the CaptureAllClasses() function. If you Record Class | Scripted and then press Ctrl+Alt, SilkTest again will search and discover all public information. You then have the option of copying the data to the frame file.

Please note that both of these methods currently apply to the Classic Agent only. This may change with a future release of SilkTest.

There is a project appended to this paper (getMethods.stp) that shows how to retrieve and use the public methods belonging to the dotnet 1.1 test application supplied with the SilkTest installation package. The sample script shows how to retrieve the height of a textfield. Please unzip the package into C:\Program Files\Borland\SilkTest\Projects\getOtherMethods. This sample deals with an ActiveX control; extensive information on dealing with Java controls (assuming a default installation) can be found in Start | Programs | Borland | SilkTest <ver> | Documentation | SilkTest Tutorials – select Testing Java Applications.

Extending Existing Classes

You can add partial support for the custom objects by creating a class derived from AnyWin and writing methods that use the primitive methods of the AnyWin class (such as TypeKeys() and MoveMouse()) to implement as much as possible the methods appropriate for the custom control. Please note that it is not possible to create all-new classes from scratch and that the AnyWin, Control, and MoveableWin classes are logical (virtual) classes that do not correspond to any actual GUI objects, but instead define methods common to the classes that derive from them. Any extensions added to these classes will not be inherited by their children.

Attached to this paper is a zip file (olegrid.zip) that contains a project and its supporting sample application that illustrates how to extend the standard OLEGrid class to a new class (MyOLEGrid) and how to retrieve information from the public classes exposed by the CaptureObjectClass() method. Please unzip the package into C:\Program Files\Borland\SilkTest\Projects\OLEGrid.

The Extension Kit

If the custom control has been developed in-house then the Extension Kit can be utilised to ‘teach’ SilkTest how to directly interact with the control. The description and use of the Extension Kit is beyond the remit of this paper; however, additional information in the form of an FAQ can be found on the Borland Support website here for Win32 applications and here for the dotNet version. The Extension Kit does not require an additional license and is installed by running the SilkTest installer and selecting the Extension Kit when presented with the list of installation options.

Try doing this and let me know if it helps

1. Copy the SilkTest_Java3.jar file from SilkTest\JavaEx folder to the JRE\ lib\ext folder.2. Rename the file access3.prop in the Silk Test folder to accessibility. Properties.3. Copy the accessibility. Properties file from Silk Test folder to JRE\lib folder.4. Copy the files qapjconn.dll and qapjarex.dll from Silk Test\Extend folder to Windows\System32 folder.