Writing good test codes are hard. Everyone struggles with it at some point. But with practice, everyone can write clean, readable test codes. Here are some ways to help you.

1. HOW TO TIDY UP
YOUR TEST CODE

2. rockinterview.in
The need for a quality test code
Developers put a lot of rigor into creating good code
structure in terms of naming conventions for classes
and methods, putting them in right packages, grouping
them correctly and adopting good processes.
Although most often ignored, clean code rules can
similarly be applied to test code as well.
There are some tell-tale signs that your test code is
not as solid as you want it to be.
Your test code is messy.
You are not sure about which part of the code
does what.
Your builds are failing.
You fear making any changes to the code lest the
change breaks something else.
Code Smells litter test code
A code smell is an implementation
that violates fundamental design
principles in a way that may slow
down development and increase
the risk of future bugs.

3. 7 WAYS TO TIDY
YOUR TEST CODE

4. rockinterview.in
Classes are longer
For execution of automated test, the code needs to open your application in a
browser, perform the necessary actions on the application, and then verify the
resulting state of the application.
These are distinct responsibilities and should not be together within a single class.
This is a code smell which makes it difficult to understand what is contained within the
class, which can lead to redundancy and maintenance challenges.
To clean this smell, separate each of these responsibilities in separate classes. This
can make it easier to locate the code, spot redundancy and simplify maintenance.

5. rockinterview.in
Methods are longer
Similar to long class smell, the long method smell occurs where a method or function
has too many responsibilities.
Challenges with readability, redundancy and maintenance are also common here.
While starting out most methods are small, but over time it grows and becomes
complex. This makes testing difficult while calling the method.
The solution for this is similar to the long-class smell. Separate the concerns, but this
time into individual methods with a single focus.

6. rockinterview.in
Code Duplication
While doing test automation, it’s common to come across the same piece of code
over and over. Repeating the same logic multiple times in various places is a case of
code smell.
If there is a change within the application within this flow, you will again have to find all
the places where this logic is duplicated within your test code and update each one.
This is time consuming and poses the risk of introducing a bug in the code.
To address this, you can abstract out the common code into their own methods. With
this, the code exists only in one common place, can be easily updated when
required, and can be called by methods that require it.

7. rockinterview.in
Flaky Locator Strategy
To make UI automation work, you need to provide your tool with identifiers to the
elements that you’d like it to find and interact with. Use of flaky locators that are not
durable is also an awful code smell.
Flaky locators are typically ones provided by a browser in the form of a “Copy Xpath”
option or something similar. The resulting locator is usually one with a long ancestry
tree and indices.
While it might be easy to make this work at the time of capture, it is extremely fragile
and susceptible to any changes made to the page structure. It is a leading cause of
false negative test results.
To fix this, make use of reliable locators such as id or name. For cases where more is
needed – such as with CSS selectors or XPath – craft your elements locator with care.

8. rockinterview.in
Exposing the code internals
Classes and methods should not expose the internal working of the code. It is
important to hide internal framework code from test layer.
It is a code smell to expose class fields such as web elements used in Page Object
classes, or class methods that return web elements.
To get rid of this smell, narrow the scope of your framework code by adjusting the
access modifiers. Make all necessary class fields private or protected, and do the
same for methods that return web elements.

9. rockinterview.in
Inefficient waits
In automated code, we have to often introduce pauses or waits to the test code. As
the automated code works faster, slowing the code down provides the
much-needed time for the application under test to process an action.
However, introducing a hard-coded wait that tells the test to pause for x number of
seconds is a code smell. It slows down the overall test execution time and different
environments may require different wait times.
To resist this smell, consider using conditional waiting techniques. Several browser
automation libraries, such as Selenium WebDriver, have methods of providing
responsible ways to wait for certain conditions to occur before continuing with
execution.

10. rockinterview.in
Multiple Points of Failure
To ensure that the classes are focused on their responsibility and nothing more, test
code is separated from the framework.
Adding assertions within your framework code is a code smell. The code’s
responsibility is not to determine the fate of a test. By doing so, it limits the
reusability of the framework code for both negative and positive scenarios.
To avoid this smell, remove all assertions from your framework code. Allow your test
code to query your framework code for state, and then make the judgement call of
pass or fail within the test itself.