1. Introduction:
The purpose of these
guidelines is to provide coding style standards for the development of source
code for automation testing written in java. Adhering to a coding style
standard is an industry proven best practice for making team development more
efficient and application maintenance more cost-effective. While not
comprehensive, these guidelines represent the minimum level of standardization
expected in the source code of projects written in java.
This document
describes rules and recommendations for developing applications and class
libraries. The goal is to define guidelines to enforce consistent style and
formatting and help automation testers to avoid common pitfalls and mistakes.
2. Terminology and Definitions
2.1 Access Modifier
Java keywords public, protected, package
(default), and private declare the allowed code-accessibility of
types and their members. Although default access modifiers vary, classes and
most other members use the default of private.
Public: No
restricted access.
Protected: Access
is limited to subclasses in other package or any class within the package of
the protected members' class.
Package
(default): Access is limited to only within package.
Private: Access
is limited to within the class definition
2.2 General Naming Conventions in Java
Camel Case
A word with the first letter lowercase, and the first letter of each subsequent word-part capitalized.
A word with the first letter lowercase, and the first letter of each subsequent word-part capitalized.
Example: customername
Pascal Case
A word with the
first letter capitalized, and the first letter of each subsequent word-part
capitalized.
Example: customername
Lowercase
Where all the
letters in a word are written without any capitalization
Example: while,
if, mypackage
Uppercase
Where all the
letters in a word are written in capitals. When there are more than two words
in the name use underscores to separate them.
Example: MAX_HOURS,
FIRST_DAY_OF_WEEK
Mixed Case
It is same as
Camel Case except the first letter of the name is in lowercase
Example: haschildren,
customerfirstname, customerlastname
Entity |
Pattern |
Examples |
|
Package
|
Lowercase
|
org.company.test.SampleTest
|
|
Class, Enum
& Interface
|
Camelcase
|
Class testcase
Interface
basetest
|
|
Construction
|
Camelcase
(Same as Class
Name)
|
Public
testcase()
|
|
Methods
|
Mixedcase
|
Gettestcasename()
|
|
Variables
|
Mixedcase
|
String
testcasename;
|
|
Constants
|
Uppercase
|
Public static
final String URL
|
2.3 Standard Java naming conventions
Refer below URL:
2.4 Commenting Conventions:
- Implementation comments are delimited by /*...*/, and //.
- Comments should be used to give overviews of code and provide additional information that is not readily available in the code itself. Comments should contain only information that is relevant to reading and understanding the program.
- All Classes should have beginning comment (c-type comment) that precisely describes the function of class
3. Standard
project structure
3.1 Solution & project naming convention
- Do not use the java reserved keywords in project name.
- Do not use acronyms that are not generally accepted in the computing field.
- When using acronyms, use pascal case for more than two characters long.
- Do not use spaces or other characters such as: ! # $ % & ' @ ^ ` ~ + , . ; = )
3.2 Directory structure:
- The src directory contains all java files and is a place holder for other java files like listener, pages, resources, tests, utility, config
- The config folder is a place holder for properties files.
- The lib directory contains required jar files, and is a place holder for other library jars/zips.
- The resources directory contains all required resources including properties files and data files, and is a place holder for other resources.
- The server directory contains selenium server jar/ chromedriver.exe/ iedriverserver.exe
- The test-output directory contains result files.
- The testng.xml file, to run test cases.
- Screenshots contains captures of pages where assertion failed.
3.3 Source code would be divided in below parts:
- Test classes: defines methods for test cases/scenarios. These method will have @test annotation
- Test page : define methods for interacting with page that includes filling data, accessing ui component, reading data from page, basic actions performed on page
- Utility classes : defines methods for other aiding functionalities
