Best Practices for Automation Framework Development with Selenium

 Before we begin, let’s just understand why we need best practices or coding practices in any development framework.

Coding conventions serve the following purposes:

•      Create a consistent look to the code, so that readers can focus on content, not layout.

•      Enable readers to understand the code more quickly by making assumptions based on previous experience.

•      Facilitate copying, updating, and maintaining the code.

•      Demonstrate C# best practices.

 

Locators are the building blocks for test automation. And choosing right locator can provide your framework stability, efficiency and robustness.

•         Why is choosing the right locator important?

–        A big part of implementing your browser based automation solution effectively, is choosing locators wisely.

–        Using the right locator ensures your tests are faster, more reliable or has lower maintenance over releases. 

–        If possible, QA can engage with developers early so that they build more reliable test cases.

 

•         How to choose right locators?

–        Selenium provides eight types of locators to identify the element in the DOM. These are Id, Name, ClassName, CssSelector, LinkText, PartialLinkText, TagName, Xpath.

–        Ids are the preferred way to locate elements on a page for 2 main reasons:

>        According to W3C, ids are supposed to be unique on an html page. This makes ids a very explicit and reliable way to locate elements on the page.

>        Sustainability:- Choosing ID provides sustainability to your automation code as no updates are required if the element is moved within the page, but if XPath was used that would require an update

>        Also, all browsers also have highly efficient methods to get an object on the page using their ids. This makes id locators the fastest type of locator in Selenium.

•         Aim for the low-hanging fruit strategy

–        One of Selenium best practices for locators is to always look for unique stuff. The idea behind this is to always aim for the “low-hanging fruit”.

–        You start with an ID, and, if that option is unavailable, resort to name attributes, class, link texts, etc. If these can’t make for a unique selector, use parent-child selectors available in CSS and Xpath.

 

Naming Standards

 

•         Naming Test Classes

–        Class names should be noun with Pascal casing.

>        Each class represents a page in application.

–        Keep class names simple and descriptive. Use whole words -avoid acronyms and abbreviations.

–        Example: class HomePage { ..}

•         Naming Methods

–        Method names should be verbs with Pascal casing.

>        Methods in automation framework can represent action of specific locator or any generic function.

–        Use whole words -avoid acronyms and abbreviations.

–        Example: public void ClickOnOkButton() { ..}

•         Naming Variables or Objects

–        Variable names should be defined with data type abbreviation followed by actual variable name with Camel casing.

>        Example: int maxCount or IConstants iConstant

–        Domain specific terminologies should be used.

–        Long names (<10 characters is a good tradeoff) should be avoided. Names that are similar or differ only in case should be avoided.

•         Naming UI Elements

–        UI Element names should follow the Camel casing.

>        Example IWebElement filterIcon

–        Keep names simple and descriptive. Use whole words -avoid acronyms and abbreviations.

–        Domain specific terminologies should be used.

–        Use appropriate prefix for the UI elements so that you can identify them from the rest of the variables. As shown below:

Prefix	Example	Description
btn	btnLogin	Button
chk	chkStatus	Checkbox
img	imgLogo	Image
lbl	lblUsername	Label
txt	txtUsername	Textbox
tbl	tblEmployee	Table
lst	lstCountry	List/IList

 

Commenting Standards

•         Comments should be added to increase the clarity of code.

•          Document something why it is done not just what it is done.

•          Every change to the framework/scripts should be documented in modification history.

•         Use the below format at the top of the test methods:-

•         Do not use inline-comments to explain obvious code. Well written code is self documenting.

•         Add “region” to represent a block of code. It makes your code readable/maintainable/ more organized. Example

Indentation Standards

•         Four spaces should be used as the unit of indentation. Tabs must be set exactly every 8 spaces (not 4).

•         Break after a comma.

•         Break before an operator.

•         Prefer higher-level breaks to lower-level breaks.

•         Align the new line with the beginning of the expression at the same level on the previous line.