Functional Test Refactoring: Introduction

This is a concise version of the article on my Medium Blog (2021-03-17).

Automated Test scripts shall be treated as production code, as David Thomas and Andy Hunt wrote in the classic “The Pragmatic Programmer” book.

Automated test scripts are often poorly designed, inefficient, hard to understand and maintain, i.e., the same issues we found in code. With coding, there is Code Refactoring, a process to enhance existing code without changing its external behavior.

My interest in web test automation started in 2005, at that time, I was a lead Java programmer. I performed code refactoring and developed (and maintained) automated UI tests daily. I gradually realized that, just like code refactoring for code, there are the same needs for automated functional (UI) tests.

I came up with a process, a set of refactorings, and a tool for enhancing the quality of automated functional test scripts. I named it “Functional Test Refactoring” (~2007).

Some manual testers may wonder: Will functional test refactoring be too technical for me? The answer is NO. In fact, every test refactoring is easy to understand and apply, each team member (including business analysts) of a software team can perform functional test refactorings.

Functional Test Refactoring

Functional Test Refactoring is a step-by-step process to refine test scripts to be

• easy to read
• concise
• easy to maintain

Automated test engineers may use recorders to assist in creating automated test steps (however, I don’t recommend this, I have always been doing it manually to choose a better locator, with extremely high efficiency. See my article: ‘Why I created a Selenium Recorder but rarely used it myself?’), but shall perform refactorings immediately. Otherwise, it leads to tech debts.

Test Refactoring Steps

The test refactorings steps are pretty much the same as the ones for code refactoring.

Before refactoring, your test script must be valid first!

1. Identify bad test scripts

2. Improve ( small step at a time)

3. Re-run the test. The novice often forgets this step.

Tool Support

If it is hard to do, people just don’t do it often.

Just like code refactoring, tool support is essential. Code refactoring only became meaningful after JetBrains first added refactoring support in its JAVA IDE: IntelliJ IDEA (around 2001). Now, all major programming IDEs support code refactoring.

• Efficient
• Reduce chances of introducing mistakes
• Easy to reach the convention

In fact, refactoring support has been named the top feature in the next-generation functional testing tools.

Next-Gen Functional Testing Tool

Agile Alliance workshop on Next-Generation Functional Testing (Oct 2007), Envision "We are lacking IDE that facilitate things like:"

* refactoring test elements

* command completion

* …

TestWise, the functional testing IDE I created, is the first (and still the only one based on my knowledge; if you do know another, please let me know) testing tool that supports "refactoring test elements".

Common Functional Testing Refactorings

The six functional test refactorings supported by TestWise are

• Extract Function
• Move Function to Helper
• Move
• Extract Page Function
• Introduce Page Object
• Rename

I will explain each of these six refactorings with video demonstrations in separate articles. Stay tuned.

Example Test (before and after refactoring)

Before

After

The test script is a lot better, isn't it? More importantly, it is much easier to maintain.

Refactorings are applicable to other languages

Functional Test Refactorings are generally applicable to all automated test scripts in different frameworks and languages. The above test script is Selenium WebDriver + RSpec. Below are two test scripts in Mocha (JS) and PyTest (Python), following the same Maintainable Automated Test Design.

--

(This article is an excerpt from my book "Practical Web Test Automation")