Coding Standards Automation Testing

Coding Standards are suggestions that will help us to write automation Scripts code using any language. Naming conventions for creating automation Script, objects, variables and procedures. Commenting standard in the scripting, Text formatting and align guidelines for the script.

Naming Conventions: Naming Conventions should be followed at all levels of the project for e.g. Variables, Constants, Objects

• Standards of Variable Naming

For easy readability purpose use the prefixes like below examples, along with descriptive names for variables in Automation Script code.

Ex:
String --sName
Object --oObjectname
Integer,Byte,Long --nNumber
Array --arrListitems
Boolean --bYes
Single,Double --fPrice
DateTime --dToday
Error --errResponse
Currency --cRupees

• Standards of Constant Naming

Constant names should be in uppercase with underscores (_) between the words.

Ex:USER_LIST_MAX, NEW_LINE

• Object Naming Standards

For the objects created in the Automation script, use prefix “o” (small letter o).

Ex:
ADODB.Connection -- oConn
ADODB.Recordset -- oRset
Scripting.xmlobject -- oXmlobj
Scipting.FileSystemObject -- oFsobj
Scipting.TextStream -- oTxt
Scripting.Dictionary -- oDic
Shell.Application -- oWsh
Excel.Application -- oXls

Reusability: Abstraction to be followed for Code Reuse at all possible levels – function library, config file, POM

POM (Page Object Model) based approach
• POM approach is to create a separate class file which would find web elements , fill them or verify them. This class can be reused in all the scripts using that element. In future if there is change in the web element , we need to make change in just 1 class file and not 10 different scripts.
• This Page class will find the WebElements of that web page and also contains Page methods which perform operations on those WebElements
• A lot more expressive as we look at the code. With well named methods, we create a higher level of abstraction that is easier to read and understand
• If the UI changes (an id of a field), we go to our one method, update the id and we are good to go

For frequent changes we use Excel sheet or CSV file

• We can use excel sheet for storing our test data. It is easy to maintain the data in excel and also easy to modify the test data as per the business requirements.

Use custom exception which can be easily understood

Custom exception helps to clearly understand the error. Please find below some key points for using custom exceptions:
• Add situation specific data to an exception. Ideally this data would help another developer to track down the source of the error.
• Provides a type safe mechanism for a developer to detect an error condition. 
• No existing exception adequately described my problem.

Maintainability and Extensibility:
• Use of Interface based programming to achieve the maintaince of existing scripts and extension of new ones

Portability.

• Code often has to run on different hardware or be compiled with different compilers. If it follows a set standard, it will likely be easieror even completely painlessto move it to a different platform.

No hard coding to be used unless absolutely necessary.

Documentation to be taken care at all levels of project.