Salesforce recommends developing custom code and custom low-code in Sandbox Orgs and performing thorough testing before deploying them to production.

For code, Salesforce enforces test coverage: You need to run tests and ensure 80% or more test coverage for all your custom code before you can push your code to production. This means your test classes have to cover 75+% of the custom code lines in your Org.

For flows, there is no such requirement. You could develop in production or deploy flows without testing first in the Sandbox. However, this approach is not recommended.

Until now, there was no easy way to run and rerun prebuilt tests for your flows similar to the test class functionality for code.

With Winter 23 Release, you received the flow testing functionality (GA) that gives you this feature for record-triggered flows.

Why would you use flow tests?

• Flow tests make rerunning the tests by you or your colleagues much easier and faster. ⏩
• When you build new automation, you can now run/rerun all existing tests in your Org. ♻️
• Before Salesforce releases, you can retest your existing flow automation running on the new API version for release readiness purposes. 💻

How does it work? How do you create flow tests in Salesforce? There are two ways:🧪 “Convert to test” button: Run a debug and convert the successful debug run to a flow test.🧪 “View tests” button: Open the tests screen and create a test using the wizard.

There are three main components to a flow test in Salesforce:1️⃣ Set test details: Set parameters such as Create/Update, and Immediate/Scheduled Path.2️⃣ Set triggering record: Set the field values for the test record, including values for after update if the test is for update.3️⃣ Assertions: Set the expected outcome and custom error messages if the expected outcome is not observed.

What are assertions? Assertions are logical statements that can evaluate as true or false. They are intended to test the expected outcome of the flow automation to decide whether the flow passed the test or not. A good example is “Does Opportunity Stage equal Qualification?”: True/False.

Observations:

• Test records: When you create your test, you can point your test to a record. As a result, the test inherits the field values from this record. However, you can modify these field values before finalizing your test. Your test is not linked to this record but contains and uses its field values.
• Decision outcomes automatically create boolean variables. The variable is set to true when the flow goes down the associated path.
• Actions in flow may create output variables. You can check the value of this variable. Some actions may not have any output variables. Then it becomes a difficult task to check whether the action was completed successfully. Email Alerts seem to auto-create a boolean variable with the same name. I assume this means the action was completed successfully, but I am not sure. I am still researching this topic.
• You can use the “Was Visited” operator to evaluate whether a particular element was visited on the executed flow path.

Limitations:

• There is limited information out there about flow testing. The release notes site for Winter 23 has a dedicated page that contains only a brief paragraph. This is not sufficient.
• Update: Followers reported tests are visible in change sets (Check the comment by Yumi below). /*I don’t believe you can deploy these tests via a change set. If you are working with change sets, this is a significant limitation. You will refresh your Sandbox eventually, and you may lose the tests in it.*/

This post was originally made to LinkedIn on October 24th, 2022.

Read the previous post: Migrate to Flow Best Practices