Let's start with the basics.
What kinds of flows are subject to code coverage requirements?
Flow test coverage requirements are only mandatory for auto-launched flows; all other flow types are exempt. However, it is recommended to write unit tests for record-triggered flows as well. Record-triggered flows behave like triggers, and writing unit tests for them increases the robustness and quality of your code.
How can you identify what flows are subject to code coverage requirements?
SOQL queries will come to your rescue when identifying which flows in your organizations need code coverage.
There are three useful SOQL queries: one to identify the list of automations that require code coverage, another to identify which flows do not have coverage, and the last to calculate the code coverage percentage for automations. In each case, you should use the Developer Console to execute them, and be sure to check the option "Use Tooling API.“
Now, let´s review each query.
Identify automations with code coverage requirements
The first query returns the name of all active auto-launched flows, workflows, custom events, or invocable processes created in your organization. Those are automations that have code coverage requirements. Remember, you can remove process types from the filter to accommodate your needs.
Identify what flows do not have coverage
Query the Flow Test Coverage object to get that information because it represents test coverage for a flow or process. It is created/updated when unit tests are executed, and deleted when changes are made to the flow version covered by the unit tests. For a flow, Apex tests execute the active version. When a flow has no active version, Apex tests execute the latest version.
Calculate code coverage
To calculate your flow test coverage, first determine the number of all active versions, with or without test coverage, and all inactive versions that are the most recent with test coverage. Let's call this number “A,” and we’ll divide it by “B,” which is the number of all the latest flow versions that have test coverage. You can get this information using queries.
A =
B =
CC% = B/A
About Apex unit tests
The Salesforce platform has a testing framework for writing and executing unit tests for Apex Classes, Triggers, and Flows. Unit tests are class methods that verify whether a particular piece of code is working properly. One important thing to note is that the framework does not offer declarative ways to write test cases.
Apex unit tests are important because they facilitate the development of robust and error-free code. They provide efficient ways to automate manual testing and identify regression bugs caused by code refactors at early stages. They also serve as documentation.
In the Salesforce ecosystem, at least 75% of your code and active flows* must be covered with unit tests in order to deploy to production.
Test methods have to be written inside a test class. They are static methods that have to be annotated with the @isTest annotation.
According to the book "Clean Code" (a recommended reading if you are passionate about software design and best practices), unit tests should be structured according to the Given-When-Then pattern.
- Given: Set up the test data, mocks, or any artifact needed to perform the test.
- When: Do your magic! Invoke the code that you want to test.
- Then: Verify that the expected behavior or output occurred.
So, how can you write effective Apex unit tests for Salesforce Flows?
Simply put, you have to write test methods for auto-launched flows and record-triggered flows.
Record-Triggered Flow
To test Record-Triggered flows, we have to write unit tests that mimic the conditions that trigger the execution of the flow and then add asserts to verify if the related actions were performed. To mimic the conditions, you have to insert, update, or delete a record that meets the conditions monitored by the flow.
For example, let's consider a flow that sets the closed date of a record when its status changes from “In Progress” to “Closed.“
Auto-launched Flow
Auto-launched flows execute a process in the background in a transparent way for the end user. These flows are a little bit harder to test than record triggered flows because you have to use the methods available in the Interview class to mimic the running conditions.
For Example, let's consider a flow that adds two numbers.
Tips: the name of the input variables is case sensitive.
Screen Flows
Screen flows let us build interactive screens, making them an amazing tool to collect user input. This flow type does not count against code coverage, so unit tests are not needed. However, if Apex code is invoked from the flow, unit tests for the Apex code have to be written.
Scheduled Flows
Scheduled flows execute processes based on a given frequency. This flow type does not count against code coverage, so unit tests are not needed. As for screen flows, if the Apex code is invoked from the flow, unit tests for the Apex code have to be written.
We’ve reached the end of this article, with all the information on code coverage requirements for tests we know. We hope it helps you to better understand the process of writing tests, and that it helps you get the most out of Salesforce Flow.
