WinRunner Coding Standards

1) No hard coded paths.

A WinRunner test should be able to be copied from one machine to another and run without any problems. Anything the test depends on (gui maps, text files, compiled modules, dll's) should be in the same parent folder as the test.

Exception:

Paths to permanent files on the K drive can be hard coded if absolutely necessary. (Warning – you may run into problems with tests running simultaneously on different machines accessing the same files on the K drive)

Wrong:

reload("C:\\WR_TESTS\\Acceptance_6\\acceptance_functions");


Right:

reload(getvar("testname") & "\\..\acceptance_functions");


2) Indent blocks of code for readability

Wrong:

for(counter = count - 24; counter < count - 1; counter++)
{
list_get_item("ListBox",counter,item);
str = str & item & "\r\n";
}

Right:

for(counter = count - 24; counter < count - 1; counter++)
{
list_get_item("ListBox",counter,item);
str = str & item & "\r\n";
}

Right:

for(counter = count - 24; counter < count - 1; counter++){
list_get_item("ListBox",counter,item);
str = str & item & "\r\n";
}



3) Avoid hard coding testing environment dependencies

Do not hardcode information which my change depending on testing environment. These include installation directories, DSN names, names of database servers, database usernames, and database passwords. It's better to define these in variables at the beginning of the test, so you do not have to make multiple changes throughout the script to implement an environmental change.


Wrong:

set_window("SQL Server Login",10);
edit_set("Login ID:", "sa");
edit_type("Password:", "password");

Right:

db_username = "sa";
db_password = "password";

set_window("SQL Server Login",10);
edit_set("Login ID:", db_username);
edit_type("Password:", db_password);

Wrong (also violates coding standard 1):

invoke_application("C:\\iAvenue\\Windows\\UAdmin.exe","","c:\\Power_db",SW_SHOW);

Right:

install_dir = "c:\\iAvenue\\Windows";

invoke_application(install_dir & "\\UAdmin.exe","",getvar("testname") & "\\..\Power_db",SW_SHOW);

4) Use text recognition as a last resort

Text recognition takes a lot of memory, can be unreliable, and can have varying results on different operating systems. It should therefore only be used if there is no other way to get the information from an object. Unfortunately, this is often the case, especially when the object is not recognized (class: object). In the following example, assume that "Assign Date" is class edit:


Wrong:

obj_get_text("Assign Date", text);

Right:

edit_get_text("Assign Date",text);



5) Do not use excessive wait statements. Try to use synchronization functions when waiting is required.


Wrong:

wait(40);


Right:

statusbar_wait_info("Status Bar","value","Sites processed = 20",40);



6) Do not use report_msg as a substitute for tl_step.

Nobody wants to read every line of the test results looking for a failure. It's much easier to look for green or red. It's OK to have a tl_step failure without a tl_step pass.

Wrong:

if(win_exists("Active Information Manager",1) == 0)
{
set_window("Active Information Manager", 1);
obj_get_text("AfxWnd42", text);
my_gui_checkpoint(text,"AIM.log");
}
else
report_msg("AIM failure! Window absent at startup");

Right:

if(win_exists("Active Information Manager",1) == 0)
{
set_window("Active Information Manager", 1);
obj_get_text("AfxWnd42", text);
my_gui_checkpoint(text,"AIM.log");
}
else
tl_step("AimReportRuns",FAIL,"AIM window absent at startup");







7) Use regular expressions to avoid multiple window instances in the gui map.


Wrong:



7) Use regular expressions to avoid multiple window instances in the gui map (continued)

Right: