4Test Coding Standards

waisttherapeuticSoftware and s/w Development

Nov 4, 2013 (3 years and 9 months ago)

95 views

Borland

Soft
ware

4Test Coding Standards

Page
1

of
9


4Test Coding St
andards


QA
Engineering Level: Beginn
er/Intermediate


It is standard in the programming world to use a variable
s

naming convention called
Hungarian Notation. Although 4Test is not a programming language
per se
, for clarity and
ease
-
of
-
mainte
nance it is recommended that QA engineers stick to Hungarian Notation
when devising SilkTest scripts.

This document will give a short rundown on

the

Hungarian
Notation convention

suggested for the 4Test scripting language.
Hungarian Notation
was
devised

by

a Hungarian, Charles Simonyi, who worked on the Excel and Word
programming teams at Microsoft.

This is not a comprehensive list of available Hungarian
Notation types but only those that apply directly to the 4Test language.


The main function of Hungarian

Notation is to tell the person reading the code exactly
what information they can expect to find within any given variable

or constant
. It does this
by appending a specified suffix of between one and fou
r letters to each named variable

and
constant
.

All H
ungarian Notation is written in lower case letters with the start of the name
itself being a capital letter.


It is also highly recommended that
both
variable
s

and constants

are called something that
explains what
it

is doing, where it originates from or
in the case of an object, what the
object is. This is normally done by concatenating one or more words from the spoken
language of the programmer.
If a variable name is constructed of more than one word, then
each subsequent concatenated word will also beg
in with a capital letter.
There is one minor
exception to this and that is when one of the words is itself an acronym; in this case the
acronym is in upper case and it is separated from the following word by an underscore e.g.


STRING
sRoad

INTEGER

iMoney

REAL
rIRA_Balance



Variables and Datatypes


All variables

and datatypes
must be declared before use.

It is very bad practice to suddenly
realise you need a variable
or datatype
of type X and simply declare it inline as part of the
code; although this is l
egitimate usage it makes your code almost impossible to read both

by yourself and anyone else who

has to maintain it.

Put all your variable and datatype
declarations at the top of your

testcases and functions where they can be found quickly and
easily. It
is also very good practice to initialise each variable after you have declared it and
before you use it; this puts it into a known state before usage. You will find that SilkTest
requires you to initialise some variables but isn’t quite so fussy about othe
rs; in the former
case it will throw

a compile
-
time error for every uninitialised variable
. However, for
consistency and clarity initialise
everything

before use

(even if the variable or datatype is
initialised to empty or zero),
unless

it is one
of those
datatypes that is
initialised on first
use
.

Conventi
on also requires that the dec
l
a
r
at
ion of a data type is in upper case letters.


All variables should be local to the function or testcase in which they are used. Although it
is possible to declare and us
e variables globally (that it, available to be read and changed
Borland

Soft
ware

4Test Coding Standards

Page
2

of
9


by all testcases and fu
n
c
tions in a project), it is discouraged

unless absolutely necessary

because it can create quite serious problems of data consi
s
tency during

distributed testing.


Data

t
ype

Prefix

Sample Declaration

Sample Initialisation

or Usage

ARRAY

ar

ARRAY arData[etc]

arData[0][0]

(dimension as require
d)

ANYTYPE

a

ANYTYPE aTempData

aTempData=0

BOOLEAN

b

BOOLEAN bAnswer

bAnswer = TRUE

DATACLASS
#

dc

DATACLASS dcOK

dcOK = PushButton

DATATYPE
#

dp

DATATYPE dpData

dpData = STRING

DATE
#

d

DATE dToday

dToday = “2006
-
03
-
17”

DATETIME
#

dt

DATETIME dNow

dNow =

“2006
-
03
-
17 12:00:00.00000”

GUITYPE
#

g

GUITYPE gPC

gPC = GetGuiType()

HANDLE
*#

h

HANDLE hFileName

hFileName = FileOpen(…etc)

IN
TEGER

i

INTEGER iCount

iCount = 0

NUMBER

n

NUMBER nTotal

nTotal=23.7

LIST

OF <type>
#

l<t>
$

LIST
OF

STRING

ls
Names

lsNames = (…etc)

LONG

l

LONG lDecimal

lDecimal = 1.2361

REAL

r

REAL rMileage

rMileage = 10.07

SEMAPHORE

s
em

SEMAPHORE
semAlpha

semAlpha
= 1

STRING

s

STRING sForename

sForename = “”

TIME

t

TIME tNow

tNow=”12:00:00.00000”

WINDOW

w

WINDOW wMainWin

wMainWin = (…etc)


*

You may find the HANDLE data type written as

HFILE or HDATABASE depending on where they are
being used, but these
two defi
nitions are simply aliases of HANDLE.

#

Initialised on first use.

$
Lists
can be of specific types
-

string, integer, window, anytype etc. The
example shows a LIST OF
STRING (ls); the convention here is that the letter l will be followed by the letter that
indicates the
type of
the
contents e.g.



LIST OF STRING lsNames

= (…etc)


LIST OF INTEGER liFigures

= (…etc)


LIST OF WINDOW lwFirstPage

= (…etc)



The same naming convention should be used for classes

of objects within the AUT.


Class

Prefix

Example

Che
ckbox

c
hk

chkYesNo

Combobox

c
bo

cboDoors

ChildWin

chld

chld
Document

DataWin

d
tw

dtwCustomers

DialogBox

dlg

dlgOpen

DyanmicText

dyn

dynStatus

Header

hdr

hdrFileName

Horizontal
scrollbar

hsb

hsbView

ListBox

lst

lstCountries

ListView

l
sv

lsvContents

MainWin

main

mainEditor

Borland

Soft
ware

4Test Coding Standards

Page
3

of
9


Menu

& Menu Items

mnu

mnuFile

PopupList

pop

popSelectItem

Pushbutton

cmd

cmd
Cancel

Radiolist

rdl

rdlOptions

Scale

scl

sclVolume

Spinner

updn

updnScale

Static Text

lbl

lblForeName

Status Bar

stb

stbOverWrite

TextField

txt

t
xtInput

Toolbar

tlb

tlbButtons

Treeview

trv

trvEmployees

Vertical
scrollbar

vsb

vsbView


Using this type of
accepted
naming convention should avoid any conflict with
the
reserved
words in 4Test.


Each class of object has a known set of data members. W
hat follows here is purely a
suggested naming convention
for use with the 4Test language and has no counterpart in
any other language. It is p
resented here because it
can
potentially
make your test scripts
even more readable
by having a specified conventio
n for

the object’s

data members too
.

This is not a comprehensive listing and you may wish to
use this list as a basis for a

company reference.


Data Members

Data Type

Return Type

CheckBox



sCaption

STRING

Expected caption of the object.

bExpected

BOOLE
AN


Expected value
s
:

TRUE for checked,




FALSE for unchecked

ChildWin



sCaption

STRING

Expected caption of the object.

iChildren

INTEGER

Number of child objects in the
Window
.

ComboBox



sCaption

STRING

Expected caption of the object.

iCount

INTEG
ER

Expected number of items in the ComboBox

lsExpected

LIST OF
STRING


Expected contents of the dropdown.

iSelIndex

INTEGER


Exp
ected selection's index value.
May be
NULL.

sSelected

STRING

Expected selection. May be NULL.

DynamicText



sExpected

STR
ING

Expected value.

Header



lsPropList

LIST OF
STRING


Text properties of the object.

ListBox



sCaption

STRING

Expected caption of the object.

iCount

INTEGER

Expected number of items in the ListBox

lsExpected

LIST OF
STRING


Expected contents of
the dropdown.

Borland

Soft
ware

4Test Coding Standards

Page
4

of
9


bExtend

BOOLEAN

Whether or not it is an extended
-
selection ListBox

iSelIndex

INTEGER


Expected selection's index value. May

be NULL.

bMulti

BOOLEAN

Whether or not it is a multi
-
select

ListBox

sSelected

STRING

Expected selection. May b
e NULL.

lsSelected

LIST OF
STRING


Expected selection. May be NULL.

ListView



sCaption

STRING

Expected caption of the object.

iCount

INTEGER

Expected number of items in the ListView

lsExpected

LIST OF
STRING


Expected contents of the dropdown.

bE
xtend

BOOLEAN

Whether or not it is an extended
-
s
election ListView

iSelIndex

INTEGER


Expected selection's index value. May be
NULL.

bMulti

BOOLEAN


Whether or not it is a multi
-
select
ListView

sSelected

STRING

Expected selection. May be NULL.

l
sSelec
ted

LIST OF
STRING


Expected selection. May be NULL.

Menu



sCaption

STRING

Expected caption of the object.




iCount

INTEGER

Expected number of items in the menu.

Menu
Item



b
Expected

BOOLEAN

Expected value:

TRUE for checked,

FALSE for unchecked

PageList



iCount

INTEGER

Expected number of pages in the PageList.

lsExpected

LIST OF
STRING


Expected contents of the PageList.

iSelIndex

INTEGER


Expecte
d selection's index value. May
not
be NULL.

sSelected

STRING


Expected page selection. May not
be
NULL.

PopupList



sCaption

STRING

Expected caption of the object.

iCount

INTEGER


Expected number of items in the
PopupList.

lsExpected

LIST OF
STRING

Expected contents of the PopupList
.

iSelIndex

INTEGER


Expecte
d selection's index value. May
not
be NULL.

sSelected

STRING


T
ext of the expected selection. May not
be NULL.

PushButton



sCaption

STRING

Expected caption of the object.

bIndeterminate

BOOLEAN


Whe
ther or not it i
s indeterminate


(Toolbars only.)

Borland

Soft
ware

4Test Coding Standards

Page
5

of
9


bPressed

BOOLEAN


Whethe
r or not it i
s pressed
(Toolbars
only.)

RadioList



sCaption

STRING

Expected caption of the object.

iCount

INTEGER


Expected number of items in the
RadioList.

lsExpected

LIST OF
STRING

Expected contents of the RadioList

iSelIndex

INTEGER


Ex
pected selection's inde
x value.

May not
be NULL.

sSelected

STRIN
G


T
ext of the expected selection. May not
be NULL.

Scale



sCaption

STRING

Expected caption of the object.

nExpected

NUMBER

Expected default position in the scale.

rngRange

SCLRANGE

Expected range of the scale
.

ScrollBar



nExpected

NUMBER


E
xpected default position in the
ScrollBar.

rngRange

SCLRANGE

Expected range of the ScrollBar.

StaticText



sExpected

STRING

Expected value.

StatusBar



iChildren

INTEGER


Expected number of child objects in the

Stat
usBar.

Spinner



nExpected

NUMBER


Expected default posi
tion in the
ScrollBar.

r
ngRange

SCLRANGE

Expected range of the ScrollBar.

TextField



bAlpha

BOOLEAN


Whet
her or not the TextField should
accept alphabetical characters.

sCaption

STRING

Expected

caption of the object.

sExpected

STRING

Expected default value of the TextField.

lsExpected

LIST OF
STRING


Ex
pected default value of a mutli
-
line
TextField

bMulti

BOOLEAN


W
hether or not it's a multi
-
line
TextField

bNumber

BOOLEAN


Whether
or not the

TextField should
accept numerical values.

sSelected

STRING


Ex
pected default selection of the
TextField.

ToolBar



iChildren

INTEGER


Expected number of child objects in the

ToolBar.

TreeView



sCaption

STRING

Expected caption of the object.

iCount

INTEGER

Expected number of items in the TreeView

lsExpected

LIST OF
Expected contents of the TreeView

Borland

Soft
ware

4Test Coding Standards

Page
6

of
9


STRING

iSelIndex

INTEGER


Exp
ected selection's index value.
May be
NULL.

sSelected

STRING

Expected selection.
May be NULL.

DialogBox



sCaption

STRI
NG

Expected caption of the object.

iChildren

INTEGER

Number of child objects in the DialogBox.



Constants


Constants are those variables that cannot be changed at runtime. By convention constants
are written in all upper case and again, the name describ
es the origin or the function of the
constant.


const WIN_PATH “c:
\
windows
\



The object of using a constant is that if its value needs to be changed, then it only has to be
changed in one place and it will automatically filter right down through the rest
of the
code.



Path Names


There is an inconsistancy within Windows in that if you call for a pathname through 4Test
(or any other programming API), it will usually be returned without a trailing backslash
e.g.


c:
\
windows
\
system32



The exception is when
the path is actually the root directory, when it is
always

returned
with a backslash e.g.



e
:
\


For consistency then, if you call for a pathname always add the trailing backslash to the
string that is returned. This will ensure th
at if you need to create

a path
name by adding
information

to a returned string, you know the backslash is already there and you won’t get
any unpleasant surprises. This short function will do the job very simply.


[
-
] STRING Ch
eckForBackslash(STRING sPath
)


[
-
] if Right(sPath
,1)
!="
\
"



[ ] sPath=sPath
+"
\
"


[ ] return sPath


Borland

Soft
ware

4Test Coding Standards

Page
7

of
9


Complex Data Structures


These include any data type that contains more than one item as part of its structure and
also any aliases th
at you wish to create. In these

cases all declarations should be in upper
case e.g. an alias:



t
ype NEW_WINDOW is WINDOW


For enumerated data types we also need to formulate some way of relating the enumerated
data to the parent structure e.g.



t
ype FRUIT is enum



FR_ORANGE



FR_APPLE



FR_STRAWBERRY


If you have a great many

enumerated data types and you find that two or three letters is not
enough to recognise the parent structure, then as a last resort consider including the parent
name in the data e.g.



t
ype FRUIT is enum



FR
UIT
_ORANGE



FR
UIT
_APPLE



FR
UIT
_STRAWBERRY




Record data types should also be in upper case and their children should follow the rules
for the simple data types disc
ussed above e.g.



t
yp
e EMPLOYEE is record



STRING sFirstName



STRING sSurname



BOOLEAN bActive



DATE dStartDate



INTEGER iVacatio
nDays


There are no hard
-
and
-
fast rules for Hungarian Notation where records are concerned; you
will have to create your own. It is envisaged that this will form part of a company standard
listing for record types e.g.



EMPLOYEE empID00123



File Headers


Unless your company has its own st
andards for file headers,
all of your frame, include and
script files sho
uld have as the bare minimum

the following information in a comment
block

at the top
:
-




File name



Company name



Description of what the file contains



Creation date



The creating engineer’s name and contact information

Borland

Soft
ware

4Test Coding Standards

Page
8

of
9




Company contact information



Copyright information



Revision history


e.g.


//

*********************************************************************

//

*

NOTEPAD.INC

*

//

*******************
**************************************************

//

*




*

//

*

Frame file for Notepad Project

*

//

*

File Created: (date)

*

//

*

Engineer:

D
ai Griffiths (dgriffiths@mycompany
.com)

*

//

*




*

//

*

Copyright © (date) Company Name

*

//

*




*

//

*

Descrip
tion: This files contains all of the functions required

*

//

*

for the Notepad project:

*

//

*




*

//

*

1. GetMenu



gets the main menu headings from the Menu Bar

*

//

*

2. GetSubMenu



gets the sub
-
menus of a named main menu

*

//

*




*

//

*

Revision His
tory


*

//

*

----------------


*

//

*

Date:

(date)

*

//

*

Engineer:

John Smith (
jsmith@
my
company.com
)

*


//

*

Reason:

GetMenu
ammended to read disabled entries

*

//

*




*

//

*********************************************************************



Frame F
iles


The frame file should always be given the same name as the project and it should be stored
in the project directory. All ‘Use’ statements referencing other include files should be
made in the frame file and
not

from any of the include files reference
d by the frame file.
The reason for this is to keep all file references in one easily
-
accessible and easily
-
maintained

place.
It also cuts down on the very real possibility of
recursion where one
include file calls another which
calls a third file which
th
en calls back to the first file; the
result of this will be SilkTest crashing with an ‘Out Of Memory’ error.

Recursive errors of
this type can be very difficult to track down if you are having to deal with multiple files
having multiple ‘Use’ statements. D
on’t do it

if you can possibly avoid it
.


The ‘Use’ stateme
nts themselves should all be put

in the same place, preferably at the top
of the frame file and embedded under an explanatory comment
.



//****
******
**********************************


//Use statem
ents


//****************************************




u
se “msw32.inc”



u
se “..
\
silkfuncs
\
maths.inc”



u
se “..
\
silkfuncs
\
companyfuncs.inc”



//****************************************


Borland

Soft
ware

4Test Coding Standards

Page
9

of
9


Option Sets


If the project requires a
n option set
, it

should also ha
ve
the same name as the project and
should be saved in the project directory. As a minimum, each option set should include:
-




Any necessary UseFile statements (see Runtime | Options)



Any necessary UsePath statements (see Runtime | Options)



Object file Path st
atements (see Runtime | Options)



Any classmapping relevant to the project (see Agent | Options)



Any Agent options relevant to the project (see Agent | Options)




Original Author: James Soderberg
,
S
egue Support Engineer,
1997

Revised:

Dai Griffiths,
Borlan
d Technical

Support Engineer

, 21
st


March 2007