Drive Your Flow Development with Tests

Learning Objectives

After completing this unit, you’ll be able to:

• Apply the principles of test-driven development to building flows.
  
• Configure a flow to be ready for tests.
  

This badge is one stop along the way to Flow Builder proficiency. From start to finish, the Build Flows with Flow Builder trail guides you through learning all about Flow Builder. Follow this recommended sequence of badges to build strong process automation skills and become a Flow Builder expert.

Let Tests Drive the Rest

It can be tempting to release your beautiful new flow creation into the world as soon as it’s built. But if you do, you take the risk of the flow making unexpected changes to your org’s data. What if there were a way to reduce that risk, while also:

• Simplifying your work by developing and testing each feature individually
  
• Working through problems more quickly, because there are fewer changes to track
  
• Creating cleaner, simpler automation that’s easier to support and expand in the future
  
• Setting aside a dedicated chunk of time to focus on the quality of your automation
  

Good news, there is! Many developers accomplish all of this by using a proven risk-mitigation strategy called test-driven development.

In test-driven development, you establish desired outcomes for your automation, build checks that confirm the automation’s intended outcomes, and then build the automation. Finally, you tidy up any clutter or loose ends in your automation. You do all of this one feature at a time.

Because Flow Builder needs a few things before you can build any checks, you can't follow the test-driven development process strictly. In flows, test-driven development generally follows these steps:

1. Select one feature of your automation. In flows, a feature is usually one data element or an Action element.
   
2. Develop the feature; in other words, create the data or Action element and any other elements or resources necessary for that element to work. But don’t add anything that’s not necessary for those elements.
   
3. Define the desired outcomes for that feature in a test. Flow Builder has a dedicated tool for this, which we talk about in a moment.
   
4. Run the test to check if the feature is achieving those outcomes. If the test fails (or any previously created test fails), go back and update your flow. Repeat until all tests pass.
   
5. Clean up your work. Make names and descriptions easy for others to follow, simplify anything that can be simplified, and remove any duplicate or extra bits. Run tests as you go, to make sure everything continues to work properly.
   
6. Repeat these steps as needed, focusing on another feature each time.
   

So how do you use this process when developing flows?

We Put Automation in Your Automation

In record-triggered flows, Flow Builder contains a testing tool called… well, Tests. The Tests tool makes it easy to follow the cycle of test-driven development. It’s a place to define your flow’s desired outcomes, and then check that the flow is actually delivering those outcomes.

Most flows will have multiple tests. With the Tests tool, you can run all of a flow’s tests with a single click. In the development world, this is called automated testing. In an automated testing tool, each desired outcome is called an assertion. (To assert means to confidently state something as fact.) In an automated testing tool, assertions state the facts about what the automation should do, and the tests perform the fact-checking.

As your flow grows and changes over time, it’s important to run your tests as you build, to make sure that everything you previously built still works. Developers call this regression testing.

Though Flow Builder’s Tests feature works only in record-triggered flows, you can follow the test-driven development process for any kind of development by manually confirming that the developed feature runs correctly. The Tests tool just automates part of the process. You learn more about manual testing in the next badge, Flow Implementation II.

A record-triggered flow needs a few things before you can build its tests.

• The flow must contain at least one element on the Run Immediately path.
  
• To test an action, such as sending an email or starting an approval process, the flow must contain the corresponding Action element.
  
• To test the contents of a resource such as a variable or formula, the flow must contain the corresponding resource.
  

These requirements are the reasons why you can’t build tests before you start building your flow. Don’t worry; test-driven development is an ideal, and the important thing is to create and run tests as soon as you can.

How Flow Tests Work

In Flow Builder tests, you define the data used to simulate the flow interview. That way, the tests don’t change any of your org’s data.

A flow test has these parts.

1. Test Details, Trigger, and Path: Define how the test runs.
   
2. Initial Triggering Record: Define or choose a record that would trigger the flow to run. These values are used only in the test and aren’t saved to the database. You enter only the values that are required by the field or relevant to the test.
   
3. Updated Triggering Record: Available only when testing a record update. Define the state of that same triggering record after the update that triggers the flow. This will include the changes that triggered the flow. These values are the record’s values before the flow runs.
   
4. Assertions: Define the conditions required for the test to pass. These values are the record’s values after the flow runs.
   

Together, the Initial Triggering Record tab and the Updated Triggering Record tab create a picture of the record update that the test should simulate. The Initial Triggering Record is the sample record before the change that triggers the flow, and the Updated Triggering Record is the same record after that change and before the flow runs.

When testing a record creation, you define only an Initial Triggering Record: the created record that triggers the flow. The assertions check whether the field values at the end of the triggered flow are what you expect them to be.

In the next unit, you create tests for a flow and use them to verify the flow’s functionality.

Resources

• Salesforce Help: Testing Your Flow
• External Link: Wikipedia: Test-Driven Development