What is code refactoring and why is it important for testers?

Definition of Code refactoring

Code refactoring is a process that involves editing and cleaning up previously written program code without changing its functions.

The main goal is to make the code more efficient and maintainable, to prevent its "spoilage", namely code duplication, countless fixes, etc. Also, code quality deterioration can occur due to a developer’s writing style.

Basic refactoring techniques and rules

Red-Green-Refactor

This technique is the most popular and used in test-driven Agile development.

The main stages:

1. Stop and consider what needs to be developed. [RED].
2. Ensure that basic testing is done. [GREEN]
3. Implement improvements. [REFACTOR]

Refactoring by abstraction

This method is best suited for large-scale refactoring. This method helps to reduce unnecessary code in your work by removing subclasses, collapsing hierarchy, etc.

• Pull-Up/Push-Down. This method divides a class into two subclasses, one of which is attached to a superclass and the other to a subclass;
• The Pull-Up method pulls code parts into a superclass to eliminate code duplication;
• The push-Down method takes a piece of code from a superclass and moves it down to subclasses.

Composition method

During the development phase, developers often write long methods that are difficult to change. Compositing involves streamlining the code to reduce duplications. This is done through various processes, including extraction and inline refactoring.

Simplifying method

It is important to get rid of old code and simplify the logic. One way to achieve this is by consolidating conditional expressions and methods.

Moving features between objects

This method involves creating new classes and moving functionality between old and new classes.

Preparatory refactoring

This method takes place when a developer notices the need for refactoring while adding a new feature. It is part of a software update, not a separate refactoring process.

How does code refactoring affect a QA engineer’s work?

Let's consider this question using the example of a manual and automation tester.

Since the basic logic of the software remains unchanged, the tasks of a manual tester after refactoring are:

• comprehension testing (testing the software as the end user of the product);
• regression testing (checking whether the update did not break or change anything).

For automation testers, the situation is a bit more complicated, as refactoring often leads to automated scripts stopping working. The reasons for this are:

• changing the position of objects on the pages whose identifiers were captured in Selenium test cases. Errors occur during the repeated "run";
• occurrence of technical changes that were transferred to the version after refactoring.

Advantages and disadvantages of refactoring

Code refactoring means a kind of software upgrade, the advantages of which are: 

1. It simplifies code maintenance and updates. Clean code is much easier to update and improve. 
2. It saves time and money in the future, i.e. the likelihood of errors will be minimal, and the introduction of new functionality will be more accessible and without extensive code analysis. Working with the code will be much easier for new team members.
3. It makes maintenance and scalability easier. Imagine yourself in the shoes of a developer who needs to make changes to a “dirty” code. There is a high likelihood that you will not know what this or that modification can lead to. Eliminating this problem is one of the advantages of code refactoring.

It is much better to clean up the code now than to pay for expensive mistakes later. That's why code refactoring is done regularly.

When should you refactor the code? It's best to do it before adding updates or new features to the existing code. This will improve the quality of the product and will make it easier for future developers to work with the source code.

The Rule of Three:

1. The first time you do something, you just do it.
2. The second time, you don't like the need to repeat it, but you do it anyway.
3. The third time you do something similar, you start refactoring.

We have already discussed the advantages of refactoring. What about the disadvantages?

1. Incorrect refactoring can cause new bugs and errors in the code.
2. There is no clear definition of "clean code".
3. Improved code is often difficult for the client to recognize because the functionality remains the same, meaning the benefits are not obvious.

To summarize, too much refactoring is as bad as not doing it at all. It's worth finding the middle ground and setting aside a few days or hours for refactoring at the beginning of a sprint or the end of it. The impact of such incremental refactoring will pleasantly surprise you.