When used effectively, flows can be a force multiplier in your team’s automated testing strategy, saving you time and increasing coverage. To get the most out of the flows in your mabl workspace, we recommend the following best practices:
- Use naming conventions
- Check to see if a flow exists already
- Focus flows on doing only one thing
- Use parameters to work with different data
- Avoid “over-flowing”
Use naming conventions
When you create a new flow, the question you should ask yourself is, “How can I name this flow so that it is easy to find and understand what it does?”
Work with your team to create a flow-naming template that captures all of the information you want to view at a high level, such as:
- The application that uses this flow (if applicable)
- The module or area of focus for the flow
- The purpose or outcome of the flow
- Whether the flow uses parameters, creates a new value, works in tandem with other flows, or loops
At mabl, we use the following template for naming flows: (#/#) (type) - application - action (parameters) ( => outputs). This template helps us quickly understand what the flow does.
For example, the flow name (1/2) App - Sign Up - Create new trial user communicates the following details:
- It works in tandem with another flow - (1/2) - and it should be used first.
- It is used on the sign up form of the mabl app
- Its purpose is to create a new trial user
As another example, the flow name Func - Unique ID - Short Timestamp - Format: ‘22-09-07 11:34.11’ (=> short_timestamp) conveys the following information:
- It works like a function that generates a unique ID
- The output of the flow is a short timestamp in a specific format
Check to see if a flow exists already
Before creating a new flow, check whether your workspace already has an existing flow that you can import instead. This practice helps prevent your workspace from filling up with many similar flows and makes it easier for other members of your team to import the right flow.
If your team consistently uses flow naming conventions, it becomes easier to know whether a flow already exists.
Checking if a flow already exists helps avoid a scenario where your workspace contains many redundant flows, as illustrated below:
Focus flows on doing only one thing
To get the most use out of flows in your workspace, make sure every flow is focused on accomplishing one specific thing. When a flow accomplishes many different tasks, it becomes less reusable.
For example, instead of creating one flow that adds an item to a cart and completes the transaction, create two separate flows that focus on each task. That way, you can reuse the flows for a wider variety of testing scenarios. The “add to cart” flow could be combined with other scenarios, such as removing an item from the cart or modifying the quantity or contents of the cart.
Use parameters to work with different data
To make flows even more versatile, add parameters to control the data used inside the flow. For example, in a flow that searches for a product, you can add parameters to search for {{@flow.query}}
and ensure that {{@flow.expected_value}}
is one of the results. With parameters, you can set your flows up for data-driven testing to cover a wider range of scenarios.
Leverage flow parameters
Avoid “over-flowing”
The main purpose of flows is to efficiently add and maintain test coverage. If you spend time creating flows that are never used, writing tests will take longer than it needs to. This habit is known as “over-flowing”.
To reap the most benefits from flows and avoid “over-flowing”, work with your team to define when and how you will use flows. Only create flows if it makes sense to capture the sequence of test steps, such as in the following situations:
- Creating steps that you know will be reused
- Capturing a sequence of steps used for data generation or manipulation
- Building complex test logic
If you’re not sure you can reuse test steps in another test, don’t create a flow. Focus instead on getting the test written and running to ensure you are gaining value from that test coverage. Even if you end up creating multiple tests with similar steps, during that time you will have more tests written to ensure you can release with confidence.
Follow the failures
To avoid the pitfalls of “over-flowing” and ensure you never spend time on a flow that is only used once, follow the failures. Consider a group of tests that all fail on the same sequence of steps. Beyond knowing what is broken in your product, you also now know what parts of the tests overlap. If the failing steps aren’t already a flow, this is one of the best times to use flows.
You can fix one of the tests with a flow and more efficiently fix the others tests. By doing so, you have created a flow that you know was time well spent because you were able to identify multiple tests that benefit from it.