Avoiding The Need to Refactor Our Automation Code

At times the automation code we have in our repositories needs some refactoring. Unfortunately, in some cases, bad code does not get improved before committing it into the code repositories. This can lead to unreadable test code, random test failures, or false positives in the test runs. Here are my tips on avoiding the need to refactor our automation code 💡

First of all, why should we care about refactoring anyway? Refactoring means updating code that is not efficient. Sure, your test might run even with bad/not the best code. But is that what we really want?

After all, we are the quality department. Therefore we should care about not only improving the quality of the product we deliver to the customers but also about delivering quality ‘products’ ourselves. And in our case, our ‘product’ is our automation codebase.

Use the programming language best practices

It all starts with us writing the test code. Before we write any of it, we should at least be familiar with the basics of the programming language we are writing tests in. There are plenty of good code learning resources available that can help us with that 📃

Based on the examples in these learning resources, we can understand how to write our tests properly. Furthermore, we can also understand what coding best practices we can apply to our automation code writing. Once we are familiar with that, we can aim to write the most efficient tests from the start.

Following the coding best practices is essential, and should not only be restricted to parts of the automation. In addition, we shouldn’t skip certain parts only because they seem too ‘small’ or ‘irrelevant’. The most common situation where this occurs is typos in naming artifacts like methods, variables, or test classes.

Following naming conventions, and typing the names correctly will help find any of these artifacts, both by people who already wrote them, but also by people looking for certain bits of code (in order not to re-write existing code).

Consider the fact that ignoring to follow these ‘small’ best practices once will open the door to ignoring them again and again and again, because it is rather convenient and quite easy to do. This leads to a lot of improper automation code we will need to refactor. And of course this is valid for skipping to follow any type of coding best practices, not just the ‘small’ ones.

Write good code first

We always want to have the tests written as fast as possible. Therefore, we tend to cut corners where that is possible. But the more we do that, the worse the code will get. And more refactoring will be required. Refactoring of course means extra work.

That is because you may have wrote the tests faster, but at some point refactoring will be required, and that is when the time you saved initially will become irrelevant (since the tests required time to be refactored) ⏲ So it’s better to have a discipline when following coding best practices to increase your code quality.

But when should refactoring be performed? The first time should be at the time of writing the tests. Before you want to commit them to your code repository, evaluate the quality of the code and make any required updates.

It’s better to find any issues as soon as possible. If you fail to do so, your colleagues will point them out at the code review phase. Whenever this occurs, make sure you update the code and not force it to the repository as is.

Of course, if there is a lack of time you’ll have to, but hopefully later on you’ll have the time to revisit and fix it. But unfortunately, that rarely happens, as there is always something more important that needs to be done.

And this is one of the ways bad/improper code gets into the repositories. What’s worse is that some teams don’t even do code reviews, so any code can end up in the repository at any time.

Refactor the automation code as soon as you identify the need

Of course, at any time after code is committed to the repository, if you think about improvements you can make to the tests, you should make them. When you notice that the performance of running a test is bad, you really don’t want to continue running it the way it is, if a quick update can fix that ✅

In some cases, the performance issue can be caused by an external dependency the automation project uses (such as a library imported into the project). Luckily, since most libraries we are using in automation are updated frequently, the fix to your problem could simply be an upgrade of your dependency to the latest version.

Identifying code that requires refactoring can be done in several ways. Of course, a simple yet thorough visual inspection by the person who wrote the test code is the first step. As I said, since you already are familiar with coding best practices, it should be easy for you to identify some improper or inefficient code. Make sure to go through the code you wrote before committing it and opening the code review.

For those bits of code for which it’s not that obvious that refactoring is required, you can use a code analyzer of your choice. But you can also manually run a set of inspections whenever at any time.

Conclusion

You have tools to help you identify code bits that need updating, and plenty of learning resources to help you write one that does not need updating in the first place. So keep on writing that good code! 💫