Tag Archives: Testing

Flow, New Release

What Is The Vision For Flow Testing?

You showed great interest in flow testing when I wrote about it a few issues back. One of my concerns about this newly introduced GA functionality is that there is little documentation about it. 😟

When I shared this concern in Trailblazer communities, the Product Director for Flow Testing in Salesforce, Henry Liu, reached out. Henry and I had an open discussion on Zoom, and I asked him all the questions I had about testing. Please remember that this information is subject to the standard forward-looking statements disclaimer of Salesforce. Here is the recap of the questions I asked and the answers I received: 💡

  • Is flow testing for admins? Absolutely.
  • Will tests calculate coverage at some point? That is the vision.
  • Will a lower limit on test coverage be required before you can deploy flows to production? Salesforce asked admins this question, and the response they got was that this needs to be decided at the Org level. The vision is that this will be optional for the admin to decide.
  • Does flow testing show us that the flow will run without errors in production? Not exactly. Flow testing does not execute the actions inside the flow, for example. You can test whether the flow followed a certain path, but you won’t know that the flow action won’t yield errors when executed.
  • What should admins study to understand the principles of testing before tackling flow tests: Code testing and Apex test classes.
  • Where do you see this functionality will take us? What is the grand vision? In a couple of years, we should have an automated testing functionality that can test everything custom in Salesforce Orgs, including code.

I think the last point presents a potential future career opportunity for admins. Please note that we should expect Trailhead content on flow testing in the future. Here is a blog post by Jennifer W. Lee on this functionality.

I would like to thank Henry for his time.

This post was originally made to LinkedIn December 5th, 2022.

Read the previous post: Are You Using the Cut Functionality?

Standard
Flow, New Release

Flow Testing Is Here: Exciting News!

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

Standard