# Best Practices - Refactoring Leapwork Flows

Usually, when we start the process of 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

### When to refactor?

**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, we are 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. We 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.

**There’s a repetitive flow/part of a flow**  
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.

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

## How To Refactor?

**Look out for reusability**  
Some actions are common across tests and 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.

**Naming test cases and sub-flows correctly**  
Give proper names to the flows and, more importantly, to reusable sub-flows.

**Reduce flow/sub-flow length**  
Shorter flows/sub-flows are always easier to read, understand, and troubleshoot. When refactoring large flows we 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.

**Remove Duplicate sub-flows/blocks**  
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.

**Avoid Long Parameter Lists in Flows**  
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 our flow has more than 10 parameters then we should try to implement smaller sub-flows with fewer parameters.

**Conditional Complexity**  
If our 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.

**Remove redundant sub-flows/blocks/elements/images**  
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](https://support.leapwork.com/s/article/HowtoremoveunusedelementsfromaLeapworkfloworfolder633075f6779c6)

**Speculative Generality**  
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. To ensure that we don't have flows, sub-flows, blocks, assets, or elements for future hanging scenarios.

**Alternative flows/sub-flows with different interfaces:**  
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 in sub-flows:**  
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](mailto:prioritysupport@leapwork.com).**