Unit Testing Salesforce Flows

Flows have been around for quite some time in the Salesforce ecosystem, and are surely one of the best automation tools. During the last release, Summer ‘22, Salesforce launched a bunch of improvements regarding Flows and Flow Builder, making a clear statement – flows came to stay and become the top developing environment.

In this article, we will talk about Unit Testing in Salesforce, available in the Beta phase exclusively for record-triggered flows.

Why would you need to test flows?

You might ask yourself – is that really necessary? Well, the answer is probably yes. As you might already know, testing is recommended before implementing any declarative automation or functionality in our live environment. This statement also holds true for Flows, which according to Salesforce, will be the only declarative automation tool available going forward within the CRM.

It is known that in order to deploy your Apex code to production, at least 75% of it has to be covered by tests. On the contrary, for declarative automations, no coverage is required, although it is a good idea to fully test in order to ensure that no errors, bugs, or malfunctions will be arising in production. This way, you will be verifying no existing functionality is being corrupted or broken. Having a handy tool like Unit Testing Flows is a great way to ensure this does not happen since it makes sure the flow you developed works smoothly and as you intended.

How to access Flow Unit Testing

The first step is creating a Salesforce Record-Triggered Flow. After configuring and designing your flow, you will be able to see a button named ‘View Tests (Beta)’ available for clicking. The test is usually divided into 3 parts or sections: Set Test Details, Trigger and Path, Set initial Triggering Record, and Set Assertions.

In the first section, we need to enter the Label, Description, select whether the test needs to be run when a record is created or updated, and decide when the text needs to be run – when a record is created or a record is updated.

In the following screen, Set Initial Triggering Record, we need to specify the different values that the test will create. You can either state the values manually or select one of the existing records that already exist in Salesforce. If you select one of the latter, some fields will be automatically populated for that record.

The last part of the test is Assertions. If you are a Salesforce Developer, you probably are familiar with them and know how powerful they are when trying to achieve the highest code coverage possible. With assertions, we can make sure that our flow is working as intended, and that it accomplishes and asserts properly its functionality.

Now that we have the previous work done, we can Run the test. To do so, click on ‘View Test (Beta)’ again. In this screen, you will see the newly created test. Click on the down arrow on the right of the test, and then select ‘Run Test and View Details’. Remember that the running test will not save any changes to the database. Records created or updated by the test will always be rolled back after the transaction.

Once the test has run, a screen showing the path taken by the flow will be displayed. On the right side, you will be able to see whether your test passed or failed, along with a display of the Assertions with a brief description of the conditions. By clicking on ‘All Details’, you will be able to see all the details of the test execution, including all the steps that were taken by the flow.

Previous features to test Flows: Debug

Until now, one of the most useful tools we had at our disposal to test flows was the Debug button. Seeing how the flow runs from different perspectives and having a breakdown of each element was what made it useful. If your debug is successful, thanks to Flow Unit Testing, you can convert a previously run debug to a test by clicking on the ‘Convert to Test’ button.

How does a Flow Test Internally Work?

Sometimes we might wonder how things work in order to understand them more properly. Ashish Agarwal, in his publication on his official webpage, explains the following about the steps for carrying out a test:

Running a Test carries out the following steps:

1. Salesforce will create the record with the values that we specified under ‘Set Initial Triggering Record’ while creating the test.
2. The Flow will be executed where we are setting […] our custom values.
3. Salesforce will then execute the assertion defined in the test and validate whether the assertion has passed or not. If the assertion passes, the test result will be marked as ‘Pass’. If the assertion fails, the test result will be marked as ‘Failed’.

Now that we know how Testing Flows works, let’s discuss the pros and cons of this interesting new feature.

Considerations

On one hand, the ability to Unit Test Flows is a great feature – it enables you to quickly verify its expected results and identify possible flow-run time failures. You can create multiple tests to prove that multiple paths are working as intended, and each time the test is run, the same configuration to evaluate the flow is used. Moreover, Unit Testing Flows saves you time while improving the flow’s reliability, and by configuring the test parameters and inputs only once, the test will use the same configuration to evaluate the flow.

In some cases, we have very complex flows in our orgs that require Apex unit tests to ensure they are working properly and have coverage. With Test One, Two, Three, Test, this changes, and there would be no need to code an entire unit test – instead, you can use the declarative tools that salesforce provides with this feature to guarantee optimal flow performance.

On the other hand, Salesforce doesn’t provide Mock records, making it harder to select registers for testing – you have to choose a specific and already existing record to run the test.

Additionally, this feature (as Salesforce calls it, Test One, Two, Three, Test) is only available for record-triggered flows at this time. However, it is expected that the CRM will possibly expand it to other flow types – such as Schedule-Triggered flows, Autolaunched flows, and Platform event-triggered flows. On top of that, you cannot include flow tests in a deployment (we made sure to test it in a newly created org) or change set.

Summary

Flows have been gaining popularity and relevance within our CRM. During the latest releases, Salesforce has been pushing features and improvements to the automation tool, and nowadays it’s a great development tool with nearly everything you’d need. Test One, Two, Three, Test shows great potential as a way to ensure flow coverage, and by using it you ensure a good user experience at the customer end.

References

• https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_debug_tests.htm&type=5&release=238
• https://www.salesforceben.com/how-to-test-your-salesforce-flow/
• https://www.asagarwal.com/step-by-step-guide-to-automate-testing-of-salesforce-flows-declaratively/?utm_source=asagarwal.com&utm_medium=posts&utm_campaign=1-minute-tips