Your Variables should have names that are descriptive
and are self documenting.
And example of bad coding practices...
static function a()
for (x = 1; x < 90; x++)
As you can see...a person who is seeing this code for the first time
would have trouble trying to figure out what this function does..
the purpose of the variable "x" is readily apparent however it would be
better to rewrite it as..
static const LOOP_LIMIT = 10;
static function descriptiveFunctionName() # some comment
Just like any other structured application program the following should be taken care of:
1.Naming convention of test scripts and the folders in which they should reside should be analyzed and decided upon.
2. A convention to start every script by loading its GUI map, and setting the search path for its called test scripts.
3. Reusable parts of the test scripts should be pulled out and kept in a common folder to avoid duplication.
4.Decide whether the test scripts for the Application under test is going to be run in Batch mode or not and always run in the mode decided. Changing the mode will cause confusion and failure of the test scripts and unnecessary files in the winrunner\tmp\ folder.
5. When recording check points, care should be taken that expected results are generic. In other words expected results should not depend on the machine in which the script is recorded, because more often than not the scripts should be ported in different machines, and the expected results for the new machine will be wrong. Ex: URL of the machine in which the test script was recorded as part of the expected result is not advised.
6.The physical files in ..\winrunner\tmp should be analyzed from time to time for unnecessary files folders etc which will kill your space. Especially when you do a save as of a test script the expected results are also copied, and if you delete the check point from the test script the physical file still exists. Care should be taken that such pysical files are deleted.