JAVA Test Automation Best Practices

Abhishek Dhoundiyal
Feb 4, 2021 · 8 min read

In the time of this pandemic, it’s not uncommon for old colleagues, friends and family to reach out for your support or to have a daily chit chat.

Similarly, I had spoken to one of my friends and it felt like forever since this pandemic.

We used to work in the same company almost 5 years back and these 5 years seem to go by in a blur. Our usual or daily chit chat conversation went southwards and we started having a conversation about all the technical stuff like test automation framework, Selenium, JAVA, new technology trends, and all the stuff you can think about.

She was very worried, puzzled and confused.

He: What sort of issues do you have with your test automation system?

She: Though the automation testing has many advantages and using object model and framework ease our task, but there are various issues like Debugging the test script. If any error is present in the test script, sometimes it may lead to deadly consequences. Test maintenance is costly in case of playback methods. Even though a minor change occurs in the GUI, the test script has to be updated again. Maintenance of test data files is difficult.

He: Are you using any industry-standard frameworks? which ease your task.

She: Yes we are.

He: Then what exactly are you worried about and having difficulty with?

She: Hmm, there are many new resources complaining about code quality, as they find it very difficult to understand it. The code is old and even after using all the best market standard frameworks and object models, it still lacks quality. The complaint I get is that the code is unreadable and very difficult to debug and understand. Frankly speaking, sometimes it is difficult for me to understand it (Especially the things I had written a few months back).

Does she need to feel ashamed while admitting the low quality of the code?

NOOO!!!

Because that’s all the automation engineers forget when writing their test scripts. They add all the fashionable and good looking framework but they forget the basic fundamentals.

I’m not a superhero but I came to the rescue.

Let’s not waste any more time.

In my previous post, I talked about how to use a clean model for long term maintainability. Now, let’s focus on some Java test automation best practices!

When it comes to Good Practices, following things came into my mind:

1) Java naming conventions: Is a rule to follow as we decide what to name our identifiers such as class, package, variable, constant, method, etc. The first thing we need to focus on is the naming conventions we should use and more importantly focus on the name which should reflect what the purpose of that item is. This increase the readability of the code to a great extend.

  • classes should start in the upper case letter. Every following word needs to start in the upper case. Any other letter should be lower case.
  • methods should always start with lower case letters. Every new word that follows should start in upper case. The rest of the letters should be lower case. The same goes for variables and parameters.
  • constants should be all upper case, with words separated by underscore characters.
  • package names should be all lower case.

2) Imports: Always avoid using the * import whenever possible. Instead of importing all the classes from an external package, try to import only the ones you need. Until and unless you have more than 5 classes to import. And don’t forget to remove unused import from the test class.

3) Variables: Always understand the scope of the variable and declare it accordingly as per the need. Don’t create a variable as a class field, if you only use it in one method. In this case, make the variable local to that method, and declare it inside the method. Or, if you are using the variable only inside a ‘for’ loop within a method, declare it inside the ‘for’ loop. Before we create a new variable, consider how often you will use it in the code. Also Instead of creating variable, we should always pass the value as an argument to the method that requires it. This will save endless numbers of lines of code, this occurs frequently in our tests.

There are three types of variables in Java:

a) Local Variable — A variable declared inside the body of the method is called the local variable. You can use this variable only within that method and the other methods in the class aren’t even aware that the variable exists. A local variable cannot be defined with a “static” keyword.

b) Instance Variable — A variable declared inside the class but outside the body of the method, is called instance variable. It is not declared as static. It is called an instance variable because its value is instance specific and is not shared among instances.

c) Static variable — A variable which is declared as static is called a static variable. It cannot be local. You can create a single copy of the static variable and share among all the instances of the class. Memory allocation for static variable happens only once when the class is loaded in the memory.

4) Method

Reusability: If we follow the page object model approach correctly, we don’t need to worry about the reusability.

Overstuffed Arguments or Parameters: Most of the time it is required to create a method which accepts multiple arguments. Parameters are also something you need to be careful about. The number of parameters should be around 5 which is good. Here we can use a different approach like passing a single encapsulated object or refactoring the method, or by not passing some argument by computing them inside the method like date or time.

5) Try/catches: Biggest enemy of a test automation system is using try-catch. I am not a big fan of using it and it should be avoided completely. There is some situation where we need to use it but always try to catch an intended exception.
Example
NoSuchElementException,
StaleElementReferenceException.

6) Log: Always use the logger but only important information needs to be inserted. Also always add browser console log to your logger. it will help you to debug the issue better.

7) Commenting: They are added with the purpose of making the source code easier for humans to understand, and are generally ignored by compilers and interpreters. In future, anyone can easily understand the code.

8) IF Conditions: The other problem she was facing is related to using multiple IFs in Java. Her test automation code is full of ‘if’ blocks. As a result lines of code had increased and it is very difficult to maintain the code, There is always some condition that needs to be evaluated. Based on that we need to execute some code or another. But having too many ‘if’ blocks or too many ‘else’ branches can lead to clogged tests. So how can we refactor our ‘if’ blocks to fulfil their purpose, without affecting our tests?

Let’s have some examples that she had an encounter in her tests, and I will show you an alternate, better way of writing the same code.

1) Starting the browser:

Her way: The classic usage of type ‘if-else-if-else-if. with to many branches.

When we have such a complex structure, it is very difficult to understand the code.

The ‘No’ Variant

The ‘Yes’ Variant

Here, we can clearly see what actions will be taken and easily find what happens if the browser parameter value corresponds to Chrome. Since each ‘case’ statement has a corresponding ‘return’ statement, this will return the new instance of that browser. Also, In case of wrong arguments, here we have a ‘default’ section, where we can handle the same accordingly.

More Advance One:

In the above, we can see that sometimes we simply don’t need to use ‘if’ blocks. However, when do, we need to make sure that we don’t exaggerate with how many levels of nesting we will use inside those blocks. Try to keep the code as simple and as clean as possible. It will help you a lot when you will need to perform debugging or simply, when you will need to understand, months later, what the code is supposed to do.

Let's have some additional tips that we both share with each other:

Use these top tips to ensure that your software testing is successful and you get the maximum return on investment (ROI):

  • Decide What Test Cases to Automate.
  • Test Early and Test Often.
  • Select the Right Automated Testing Tool.
  • Divide your Automated Testing Efforts.
  • Create Good, Quality Test Data.
  • Create Automated Tests that are Resistant to Changes in the UI.

You can get the most benefit out of your automated testing efforts by automating:

  • Repetitive tests that run for multiple builds.
  • Tests that tend to cause human error.
  • Tests that require multiple data sets.
  • Frequently used functionality that introduces high-risk conditions.
  • Tests that are impossible to perform manually.
  • Tests that run on several different hardware or software platforms and configurations.
  • Tests that take a lot of effort and time when manual testing.

11 Best Practices of Selenium Automation Testing

Conclusion:

Don’t forget that our goal when we write automation code is to write clean code. This involves tidying up any unused items, like imports, variables, or even methods. Also remove any commented code, if you will never use it again. Don’t just keep commented code, in case you will need it at some point. And, before you commit the code to the repository, make sure you take a good look at what you wrote If possible, run a static code analyzer on it, so you can polish it before you make it available to your teammates.

I know when I share this article with her, she will definitely have a smile on her face. Especially the point number 1, 3 4, 5 had given her a nightmare and by using 6 she will be able to debug things easily.

Geek Culture

Proud to geek out. Follow to join our +1.5M monthly readers.