Best Practices - Refactoring LEAPWORK Flows

Usually, when we start automation, we try to create test cases as quickly as possible. In this phase, as we begin with a new tool and experience the associated learning curve, we can overlook best practices. This can make the test cases we initially build hard to maintain and scale.

To overcome these challenges, we need to look back at all test cases and modify them in a way that is scalable and maintainable. This process is known as Refactoring. Here, we can make some changes to the flows in such a way that it does not alter the functionality or external behavior of the flow, yet improves its internal structure and performance.

Why Refactor?

Refactoring helps to

• Reduce the complexity, which is otherwise ignored while creating the initial flows

• Reduce redundancy, simplify the logic, and cut down the unnecessary loops in flows that are already used

Always start from green

Never refactor anything when tests are failing. This applies to refactoring production tests, and to refactoring tests. In any refactoring, start from green (tests passing) and end in green. Otherwise, you’re not refactoring.

The test case is hard to read

The main aim of refactoring is to improve the readability of tests, making them more efficient and maintainable. In many cases, it’s not even necessary to restructure tests to do that. You can just rename a few sub-flows / building blocks or variables using more straightforward names and that will be enough to make the tests more readable.

While recording the flow there are some actions that get repeated, and repeated tests are a common problem when several testers/developers are working on different parts of the same project. Tests get repeated when testers/developers simply don’t know that someone else has already written a sub-flow they could reuse. 

It’s definitely time to refactor your tests if new features result in the appearance of bugs in areas that weren’t changed and functioned perfectly before. This means your test is flaky.

Some actions are common across tests and they should be extracted into sub-flows. Find the blocks that are used more than twice in the flow. These blocks can be converted into a sub-flow and can be reused wherever required. This will help to achieve modularity and reusability.

Give proper names to the flows and, more importantly, to reusable sub-flows.

Shorter flows/sub-flows are always easier to read, understand, and troubleshoot. When refactoring large flows you should divide the functionality in a way that converts repeated functionality into sub-flows. One sub-flow should handle one task, to ensure easy maintenance and scalability of that sub-flow.

When we work in a large team, people unknowingly create sub-flows for the same functionality with different names. During refactoring it's important to find out all sub-flows that have been named in this way and remove duplication. Similarly, we should avoid duplication of blocks.

The more parameters a sub-flow has, the more complex it is. Simplify and rationalize the sub-flow to the least common denominator for the parameters being passed. If your flow has more than 10 parameters then you should try to implement smaller sub-flows with fewer parameters.

If your sub-flow has a large set of conditional handling, then try to refine the approach by getting into a single responsibility principle. This is a sub-flow that handles one condition rather than having all conditions in one sub-flow.  

Find repeated or redundant blocks/sub-flows from the parent flows, delete blocks/sub-flows/elements/images that are not being used or leftover and redundant. For more information, go here:

How to remove unused elements from a LEAPWORK flow or folder

Creating flows/sub-flows for future use can cause unnecessary confusion within teams, as it's sometimes hard to judge the usage of these flows/sub-flows. So ensure that you don't have flows, sub-flows, blocks, assets, or elements for future hanging scenarios.

If two flows are similar on the inside but different on the outside, perhaps they can be modified to share a common sub-flow.

Data should always be part of the main flow and it should pass to the sub-flow. This ensures proper control over data flow and easy maintenance. 

So, avoid adding data directly into sub-flows. For example, using Excel in sub-flows is not good practice. Data should be passed from the main flows only.

For any clarification, please contact our Priority Support.