Member-only story
Functional Test Refactoring: Introduction
A quick, reliable, and efficient way to improve the test design of your automated test scripts
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 tester 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, I have always been doing it manually for choosing 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, leading to tech debts.
