I'm just starting a new contract and with a company that has been using Silk for the last 4 years. They have a large body of Silk test code that was written by someone who was, I'm sure, a very good C++ programmer.

The code has Application layers and "foundation" layers. It has all Afx controls mapped to AnyWin. It does not use the "testcase" keyword and, therefore, the recovery system as supplied by Segue. There are 79 .inc files, 36 .lcl files ("logical classes"), 33 .pcl files ("physical classes"), and only 6 .t files.

It has the following agent options (not set in the code, but by copying a specified partner.ini file):
OPT_KEYBOARD_DELAY=105
OPT_MOUSE_DELAY=50
OPT_WINDOW_TIMEOUT=60000

The code depends heavily on properties of instances of custom classes. There are numerous examples of properties that seem to want to track things that can be gotten with built in Silk methods. For example:

// This property contains the GuiType for the application under test.
STRING sGuiTypeInit=""
property sGuiType
STRING Get ()
return (this.sGuiTypeInit)
property gui
GUITYPE Get ()
return (GetGUIType())

Another example of "property overload" is with deeply nested controls. Rather than use the "concatenated tag" such as "#1/#1", this code uses a property to hold the intermediate levels:
property wTreeView
WINDOW Get ()
return (this.ClientArea.TreeContainer.TVGeneric)

There are things like StartFileManager () which is declared as a member of a Utility class instead of within the declarations of the File Manager.

There are instances of the same include filename in alternative directory paths. You have to edit the "starter" include file for the target GUI. Just to make things more complicated all the GUI objects are declared with mulitags. Oh, and by the way, there's no supporting documentation.

This is the third time I've seen Silk/QAP code written in a "nonstandard" way. In both cases before this I recommended scrapping the code and we recoded the tests with a more standard "out-of-the-box" architecture. So, now I'm getting ready to make the same recommendation. But before I do, I would like to hear from some other automators. Have any of you faced this kind of situation? Am I just being close-minded or is this code really just a can of worms?

Thanks to all for your input.

Steve Vizzini