I wrote this article as part of the Ministry of Testing’s Blogger’s Club. The topic for march 2022 is: ____ is an underrated skill in testing.

Test Automation is creating code to verify the System under Test. It is in fact the same as programming. Test Automation Engineers create for each test case code that is executed against the System Under Test. This testing code is not used by the end-user of the system we are creating. Is this code less important than the code in production? No, it is not! This code is for determining if the product in production is a good product or not.

The code that the test automation engineers are generating, is most of the time treated like second-hand code. I hear a lot “It is only test code” or “This code is not important because it is never deployed to production”. When people think like this, it is not surprising that test code is never refactored as it should be.

What is the reason that test code is treated so badly? Personally, I can think a few reasons:

  • Testers are happy when they can investigate things. They look not that often to production code. This code is no real product for the customers.
  • Testers are not educated programmers. Most of them learned coding in their free time. Code is copied over and over. That is normal human behavior. By copying code, the refactoring is forgotten.
  • Maybe most of the testers are not aware of what refactoring is?

What is refactoring?

Code refactoring is defined as the process of restructuring computer code without changing or adding to its external behavior and functionality.

– Stephen Watts, Chrissy Kidd

The purpose of refactoring is to rewrite the code so that it is more simple and maintainable. Then we create fewer errors in the code. For me, the DRY principle is very important. DRY is an acronym for Don’t Repeat Yourself. We try to avoid duplicate code. This can be done by placing the duplicate code in separate functions.

When do we refactor?

During implementation of tests

Suppose you are coding a new test case. The test case works as it is supposed to work. A few weeks later, you have to write another test that is very similar but not the same as this first test. You do copy some code from the first one to the second test. Now the second test works too.

You can finish now and go to the next test. You can do something else too. Determine if you wrote some code that is located in other places. After identifying the duplicate code, extract that code and place it in a function. Then replace the original duplicate code with a call to the function you wrote earlier.

This has a few advantages. When you discover an error in the code, you do not have to update a lot of code. You can fix that bug in just one place.

So it is a good practice to refactor the code while creating your code. Do not create a new task or story just to refactor the code. In that case, it is not done. If it is never done, your codebase will get unmaintainable in the end.

During code reviews

Test code is not production code. Are we going to review it? Yes, we do! Ashley Graf tells us in her blog post that reviewing is very important and has several advantages. Reviewing code is not only for production code. It is also valid for test code.

The developers in your team can review your test code. They can tell you that it is a good practice to place that code in a separate function. They can give you tips on how to implement something in a better way. When solving the review remarks, you can refactor your code to make it better and maintainable.

Conclusion

Refactoring is a good practice to create better code that is maintainable. We are advocates of good quality as testers. Then it is evident that we are following good practices that give better code quality in return.

References