Selenium Automation Good vs Bad Practices

Selenium is the most widely used open-source test automation tool for web applications in the market today. Selenium works with many browsers, operating systems, programming languages like Java, .NET, Python etc.

Automation with Selenium

Automate your success

Selenium is widely used to automate browser-based applications. Although mainly used for test automation, Selenium is not limited to testing. It can be used to automate any repetitive browser operation. There are multiple tools and plugins available to identify web elements which help in writing Selenium automation (for example, Selenium IDE, Xpath viewer, Firebug, and more). The increased complexity of UI elements makes it difficult to identify a web element uniquely, or operate on it, during automation run. This Blog includes examples with possible solutions and ways to create reliable, reusable automation projects using Selenium for beginners. The Blog(in next Blog entry) also includes quick debugging tips for Selenium automation tests. In this entry we’ll briefly touch upon what can go wrong with a poorly written Selenium automation and what should to be considered to write a reliable automation.

Bad practices to avoid
Weak element locators. Locators based on labels, titles can be unreliable and should be discouraged whenever possible.
Excessive use of xpath based locators. These can affect automation performance adversely and should only be used when the element to be identified is relative to other elements, or can not be identified by any other identification method (such as id, css, name).
Hard waits such as Thread.sleep. Hard waits make automation unreliable and slow.
The use of high implicit wait impacts performance. Implicit wait is applicable for a complete run. So minimum/optimized implicit wait should be used.
Do not put off abstracting common methods to a common reusable library.
Good practices
Write automation in a three-layer structure with Object, Task and Test case classes
Automation framework should contain object classes, task classes and test case classes. This makes code easy to maintain and enhances re-usability. This is not specific to Selenium automation only, but can be applied to any test automation framework.

Object classes:

Task classes:

A task class should include methods to operate on elements present in object classes. For example: getting a value from an element, writing to an element, checking for an attribute of an element,clicking on an element, and so on. If there are application-specific common or repetitive operations, add different task classes for them. Do not try to add everything to the same class. Ideally, task classes work as a channel between the Test case and Object classes. If an application requires data driven locators use the data as global, static variables, or enums. Write separate methods in task classes to operate on such locators

Test Case Classes:

These are the actual tests that use task classes. Test case classes do not directly interact with object classes.

Always create library classes to store re-usable code for common operations.
You’ll share and re-use these library classes in common GUI automation projects, for example (not inclusive)