AE Coding Standard Page 1 of 9

Automation Expertise Coding Standard - Version 1.3

File Organization Models

AE uses the subdirectories listed below. Test frames, include files, and option sets are stored in the general
folder.

scripts

testplans

general

results

objects

data

documentation

A source code control system should be used to track changes to the SilkTest files, ensure backups, and the
ability to roll back unwanted modifications.

User-Specific Frame Data

Depending on your application and environment, you may need to declare sLocation or sCmdLine as well as other
variables which are specific to your machine, testing needs, etc. These data members should be referenced using
a local c:\qaconfig.ini file. The test frame should read this file to determine the URL to be tested. Numerous other
variables can also be set in this file. This image shows a function which can read from the c:\qaconfig.ini

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 2 of 9

Variable Naming
Naming variables meaningful names and using codes to reflect the data type helps to make code more
maintainable. Maintainability is a core concept of Automation Expertise. Variables are named acording to
Hungarian Notation. By using a meaningful name and this notation, its easy to tell the purpose of the variable.
The first letter or letters of the variable tells what type of variable it is. For user-defined types, such as Customer
below, the Hungarian notation can still be followed.

top

Comments
Comments help to make the code more maintainable. Comments should be used extensively to explain the logic
behind most statements. They should be done in all upper case. One space should be used between the two
slashes. For extensive explanations, an indended section with a meaningful name should be used. Comments for
each line are not required. Instead, use comments for groups of closely related lines or whenever the code is
confusing or may be difficult to understand.

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 3 of 9

top

Indentation
Indentation should be used to clearly define and allow easy access to different sections of any file in SilkTest.
This includes test plans (.pln), test scripts (.t) and test frame (.inc) files. In the images below, a test script and test
frame are shown. The test script includes places for functions, global variables and application states, which are
also included in the test frame. Sometimes, these objects are placed in test scripts. See the section on File
Organization for more discussion of this subject.

Nearly all AE-developed test frames have the same look and feel. This allows for more maintainability and much
easier access to what you need to work on. The sections can be further sub-divided for clarity and accessibility.

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 4 of 9

White Space
White space is important in making the code more readable and maintainable. Blocks of code should be no more
than 5 lines without any white space or comments. White space should appear above comments. Compare the
next two images below.

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 5 of 9

Function Naming
Functions should be given meaningful names. Use of the "_" underscore character should be avoided. Instead,
ProperCase names should be used to provide meaning to the user. Examples: GetCurrentUser (), VerifyDBStatus
(), EnterNewUser (). In the image below, the functions have been given meaningful names. This also follows the
Silk naming convention.

Testcase Naming
Testcases should be given meaningful names. The use of Proper Names should be used instead of the underscore
("_") character. In the image below, there are several reusable testcases which accept parameters, passed from
the test plan using the testdata: statement. An application state can also be passed to a testcase, then executed
using the SetAppState () function.

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 6 of 9

Script/TestPlan Naming
Several things affect how scripts and testplans should be named. First, scripts and plans should have names
which are reflective of what they contain. Tests related to web site registration should be called register.pln, or
register.t. Both of these files will produce register.res. For this reason, it may make sense to name plans and
scripts with different names. For example: register_plan.pln and register_tests.t. The following items should be
considered when making this decision.

Whether plans and scripts are stored in separate directories

The number of results being kept, which is specified in Runtime Options

Whether a results directory is specified in Runtime Options

Testplan Script statement: usage

The script statement should use a relative path to refer to a test script. By using the recommended AE file
structure, the script statement can always refer to test scripts using the ..\scripts\script.t statement. This relative
path refers to a sibling directory. Hard-coded paths and machine names should be avoided in tesptlans. This
makes them very difficult to move from one machine or environment to another. In the image below, the relative
path to the script is used, making this portable to any location.

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 7 of 9

Master/Sub Plans
Master and Sub Plans allow control over the development process, ongoing completion reports, selection of
testcases, etc. See the Silk Organizer tutorial for details on use of Master/Sub Plans. Use of Master/Sub Plans is
key to the AE SilkTest methodology. A master plan can contain any number of subplans by using the include:
statement, which adds a subplan to a master plan. From a master plan, Completion Reports may be executed,
which will provide completion results for all sub-plans. These reports can be broken down by any of the defined
attributes, which are described below. A master plan can also be used to select tests using queries, and to specify
configurations before sub-plan execution.

Attributes
Attributes help to track progress and to select tests. They should be defined in a central file for each team. The
file should be stored on the network and referred to in Options > General in SilkTest. Attributes are described in
detail in the Silk Organizer tutorial. In addition to the default Attributes, AE recommends using Smoke (TRUE,
FALSE). Other attributes should be defined according to the project.

Application State: none

AE does not recommend the use of appstate none, except in special circumstances where the default application
(browser or other app) will not be used during the testcase. "appstate none" disables the recovery system
completely.

Classes vs. Functions

AE recommends using functions over methods with a number of exceptions. Generally functions are easier to
document. The decision is based on maintainability of the code. Exceptions include:

Overriding existing method for instance is required (Invoke method)

Adding functionality to custom object

Use of Enumerated Types

Enums make code more maintainable. Their usage can save significant time (and money). If the object they are
used against is modified, the enum can be updated quickly and easily. One notable built-in enum is EXCEPTION,
which includes every error SilkTest can generate. Every enum has a specific assigned negative value, which is
returned by the ExceptNum () function. By type-casting to EXCEPTION, you can retrieve a meaningful error, which
is the purpose of enums. The image below, taken from 4test.inc, shows the partial declaration of the EXCEPTION
enumerated type. This is a SilkTest file. You can learn more about creating and using enumerated types in the
SilkTest help file or documentation.

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 8 of 9

Using enums can make code much more readable. In the image below, an enum is used to make the function's
arguments more readable.

VOID Keyword
AE does not recommend the use of the optional VOID keyword. The keyword denotes that the method or function
does not return any value. The default return value is VOID, so its use is redundant. A number of SilkTest
programmers do use this keyword.

Recording Keyword
AE does not suggest the use of the recording keyword. This keyword is added automatically when recording a
testcase. After recording, the recording statement should be removed and the indented lines moved to the left.
Any lines indented within the recording keyword have the following verifications turned OFF:
OPT_REQUIRE_ACTIVE, OPT_VERIFY_ACTIVE, OPT_VERIFY_CLOSED, and OPT_VERIFY_EXPOSED.

Special Note: By adding the following lines to partner.ini, you can turn off the recording behavior described above.

[PlaybackOptions]
OPT_REQUIRE_ACTIVE=TRUE
OPT_VERIFY_ACTIVE=TRUE
OPT_VERIFY_CLOSED=TRUE
OPT_VERIFY_EXPOSED=TRUE

The image below shows a testcase recorded using Record > Testcase.

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007
AE Coding Standard Page 9 of 9

This image reflects the same testcase with the recording statement removed and comments added for clarity. The
mouse button and x/y coordinates have also been removed. The SetActive () statements have also been removed.

Visual 4-Test
AE does not recommend the use of Non-Visual 4-test. Visual 4-test offers a number of very useful features
including: immedate syntax checking, Control-. (F12) jump to any object's definition, collapsable objects, sections,
and more.

top

http://www.automationexpertise.com/coding/ae_coding_standard.htm 5/31/2007