FAQ

How can you best support changes to the UI of the AUT
(Application Under Test) - Customizing Window Tags

Detail

The ability to map a window identifier to a window tag is arguably the most powerful feature of SilkTest. By separating the logical from the physical application, 4Test provides a simple and effective way of insulating test scripts from changes in the GUI of the application under test (AUT).  For example if an edit box is labeled with the text “Last Name”, a declaration of the object would look something like this:

            TextField        LastName

               tag “Last Name”

Now let’s say that in a subsequent build, a new GUI standard is implemented where only the first letter of the first word in a label is capitalized. Furthermore, all labels are to be terminated with a colon. Even if many references were made to LastName in test scripts, the only change required would be to modify the tag as follows “Last name:”. All references to LastName are unchanged since the identifier of the object remains the same. This is significant considering how fluid GUIs are relative to the business logic that they represent. Because of this ability to separate logical from physical, 4Test test scripts are far easier to maintain than those of any other test tool in the marketplace. 

Recordable Window Tags

Most 4Test users are probably familiar with the basic sources of window tags:

  • Caption -  The caption or label as it appears to the user.

  • Prior text - The closest static text above or to the left of the object.

  • Prior text - The closest static text above or to the left of the object.

  • Index -  The order (from top left to bottom right) in relation to other sibling objects of the same class.

  • Window ID -   GUI-specific ID.

  • Location -  The physical location, expressed as a pair of (x, y) coordinates.

These tags can be recorded using Record Window Declarations and in many cases will suffice to uniquely identify an object.

Custom Window Tags

It is important to ensure that each object has a tag that is unambiguous and unique so that SilkTest will always reference the intended object. Most applications include at least a few objects where basic tags will not satisfy this requirement. In these cases, it is necessary to customize the window tag. The following examples suggest when and how to achieve this:

A DialogBox that can have different parents – One of the most common reasons to modify a window tag is to provide a choice of parent objects. The “Save As” Dialog is one example. Its parent is usually the window from which it is invoked. Its parent can be easily generalized by removing the parent statement entirely and replacing the tag with the following:

  •             tag “..\Save As”

The “..” portion of the tag represents any parent dialog. The “Save As” makes the tag specific. The full tag instructs SilkTest to reference the window with the caption “Save As” with any dialog as its parent.

A BrowserChild with a non-unique tag – Most web applications are comprised of pages that do not have unique tags. In some cases all of the pages have the same caption. In other cases SilkTest is able to use only an index (usually “#1”) to identify a page or frame. It is rarely acceptable to allow these ambiguities to go unresolved. Problems will result at runtime because SilkTest can’t distinguish one window from the next. To resolve these problems, it is necessary to make tags more specific. An easy way to accomplish this is to use a unique child of a window to identify it. For example the tag statement:

  •             tag “[BrowserChild]#1\[HtmlText]Welcome\..”

references a window of the class BrowserChild that contains an HtmlText object with the text “Welcome”. When using this technique it is essential to insure that the child object selected for the tag does not appear on any other window other than the one it is used to positively identify.

A window tag that contains variable characters – There are often times when part of a window tag will consistently identify an object, while other parts of it vary based on the context of the AUT. For example a tag for a DialogBox in an Order Entry system might contain the text of the item being ordered, e.g., ‘tag “Item – Hiking Boots”’. Obviously this tag will only correctly reference the dialog when this item is being ordered. By using the wildcard characters, “?” and *”, to replace a single character and multiple characters respectively, variable characters can be easily filtered out of tags. The tag statement could be changed to ‘tag “Item –*”’.

A toolbar where SilkTest sees only a single object – Toolbars are often seen by SilkTest as a single object. The individual tools are not distinguished, but are instead part of the rectangle of the toolbar itself. It is easy to “create” sub-objects for each of the toolbar buttons using the window tag syntax: tag “(col : ncols, row : nrows)”. Using the tool palette in Paint as an example: 

  •             AfxWnd42   ToolBar

  •                tag “#1”

  •               VOID Select (STRING sTool)

  •                         @(sTool).Click()

  •                         return

  •                Control   FreeFormSelect

  •                   tag “(1:2,1:20)

  •                Control   Select

  •                   tag “(2:2,1:20)

  •                Control   Eraser

  •                   tag “(1:2,2:20)

  •                Control   FillWithColor

  •                   tag “(2:2,2:20)

The only window that SilkTest recognizes in this example is the AfxWin42. The tools are created by imposing an imaginary grid on the ToolBar with the custom tag syntax. The first tool, FreeFormSelect, is the sub-object in column 1 of 2 columns and row 1 of 20 rows. Note in the code example above that a Select method is included making it very easy to pick a tool from the toolbar. Because the imaginary grid is superimposed at runtime, this strategy for selecting tools is robust and works across different machine resolutions.

An object whose index varies based on application context – One of the toughest window tag problems to solve occurs when SilkTest must use an index to tag an object where the index of the object changes based on the context of the application. For example, suppose that the number of TextFields on a form changes based on the input mode. Let’s say that in Add mode, LastName is the first TextField to appear on the screen, whereas in Edit mode, it is the second TextField because the OrderNumber field is added at the top of the form. If an index of “#1” is used as the window tag, SilkTest would correctly reference the LastName field in Add mode, but in Edit mode it would reference the OrderNumber field instead. One of the best ways to solve this problem is to embed a method call in the window tag for the object. The method returns the tag as the result of some conditional expression. For example:

  •             STRING GetLastNameTag ()

  •                         if InputMode.GetText () = = “Add”

  •                                     return “#1”

  •                         else

  •                                     return “#2”

  •             TextField    LastName

  •                tag “{GetLastNameTag()}”

The tag statement in this example gets its value by calling the method GetLastNameTag(). The method returns either “#1” or “#2” based on the context of the application, in this case, the value of the InputMode field.

An object where one or more instance may exists – Often in a web application, there are objects that are repeated down the length of a scrolling page. By default, these objects will be assigned a window tag that ends with an index in square brackets. For example, a link that allows the user to go to the top of a page may have a tag like “[HtmlLink]Top[1]”.  Subsequent occurrences will be assigned tags in sequence: “[HtmlLink]Top[2]”, “[HtmlLink]Top[3]”, etc. A problem may result when the number of occurrences of the link changes based on the application context. A reference to the object might result in a “Window Not Unique” error if the tag is not constructed properly. Multitags provides a good solution, but you have to be careful of the order in which the indexes are listed. For example, a tag of:

  •             HtmlLink   Top

  •                  multitag “Top”

  •                                “Top[1]”

will result in a “Window Not Unique” if there is more than one occurrence of the link. Instead the tag must be constructed like:

  •             HtmlLink   Top

  •                  multitag “Top[1]”

  •                                “Top" 

This tag construction will work whether one or more occurrences of the link are displayed on the page. 

MultiTags

A multitag statement replaces the tag statement in a window declaration when the user wants SilkTest to try to resolve more than one possible tag when attempting to reference and object.  In the example below, SilkTest will first attempt to locate an object of the TextField class using the tag “Last Name”. If it is not successful, it will then attempt to find an object of the TextField class with the index “#1”:

  •             TextField   LastName

  •                multitag   “Last Name”

  •                         “#1”

When used judiciously, multitags can help solve tough problems, but when used with abandon they are anathema because they can cause SilkTest to reference unintended objects. As a rule, the multitag option should be turned off. The user should turn it on to capture multiple tags only when the situation warrants.

Test your tags

Because Record Window Declarations captures windows more or less automatically, it can be easy to forget about window tags. But to ensure that your tests run as intended, it’s good measure to test all custom window tags. The time spent on this exercise will be re-paid throughout the life of your project.