Flow Testing

Owned by Jodie Miners
Last updated: Jun 14, 2022
6 min read

Flow Testing is new (very new) in Summer ‘22. Now, as we know from “Fields (beta)” that has been released in a state that is quite unusable then drip by drip new features each release and it’s STILL not useable, I don’t hold out any hope for Flow Testing to be useful for many releases yet. Let’s call this release a look at where they are heading with Flow Testing rather than anything you will actually use yet.

Testing vs Tests

Now for a start let’s NEVER confuse Flow Testing with Apex Tests or Tests that you need to to in order to deploy, or anything of that nature. They are different things altogether. So if your developers start arcing up about this being yet another reason to not use Flow then firstly tell them to pull their head in, and secondly, ask them to think about it as a “validation that I haven’t broken anything huge”, or “Flow debug with saved inputs” then ask them to let you know what tests they have running on that object so you can build something similar into your Flow Testing.

Help Docs

https://help.salesforce.com/s/articleView?id=sf.flow_test.htm&type=5

DO NOT look for Flow Testing on Trailhead, there is nothing there yet! This is NOT about Flow Testing https://trailhead.salesforce.com/en/content/learn/modules/flow-testing-and-distribution

Opt In

I found this one interesting… you know when you join a pilot you have to go through all this rigamarole to contact your AE then they have to do some BS behind the scenes to nominate you for a Pilot and it takes weeks, and then once you are selected you have to sign your life away by signing the “Unified Pilot Research Agreement”… well in this instance (and it is the same with Fields (beta)), you just agree by creating a new test and by that you are signing your life away… now why isn’t that just standard with any Pilot. Geez! BUT, how unbelievably bad is this for high risk or highly controlled environments where the System Admin is opting a company into a legal agreement without express agreement. This is why I don’t work for large companies. (If you do, address this sort of thing now with your legal team, as it will be used more and more).

Current State

  • Flow Triggers only

  • No Automated Test Runs

  • No testing Asynchronous paths - although they do have the drop down there, so it looks like it could be coming.

  • No testing for On Delete Flows

  • You must have View All Data to create test… which is fine, because you are only going to be System Admin creating these tests. BUT you can run tests without View All Data… but you still need Manage Flows to view Setup and view the Flows.

  • “A test can only evaluate whether a flow element was executed and whether flow resource values are set as expected”

  • “Assertions are evaluated at the end of the test run” - Interesting… I wonder if this is a “now” thing and they are planning to add any more points of testing - eg after each setting of variables it would be good to have a test as I often have variables set to different things during the course of the flow, and it would be good to set a test point for before the variable is set, and after, but then that’s me thinking like a developer and thinking of break points in testing.

  • 200 Tests per Flow (look if you are getting to be that many, it’s time to refactor your flow, and no, I am NOT starting that discussion again).

Things to Note

The Good

  • You can convert a Debug Run to a Test

  • The Test default names are pretty good - it is the API Name of the Flow then the Label for your test.

The Bad

  • No reporting on Test Results - they only appear in the Test Window.

  • Nowhere to see which Flows have Tests - I’d like a column in the Flow List View

  • Just like the Debug page the layout of the fields is automated and atrocious, especially for big objects. There must be a better way! Even if it was to just filter the fields that were on display

    • Field sets? Let us choose the set of fields that will be displayed, then choose which Field Set to display here when building tests - of course default to this standard way if necessary.

    • Have each page layout as an option - the reason this may not work is that often you don’t have fields used in your automations on the page layouts.

  • You can’t set comparative values? What? Why? I have a flow where I update one field based on the value of the other field. I want my assertion to say that those two fields are now equal. I can’t do that. I can only enter a static value or say Is Null, False.

    • Like why can’t I create Test Variables or Formulas in my Flow and use a variable here?

  • Do they not work with Person Accounts? I had this error the first time I ran the test.

 

The Weird

  • The “wizard” for building tests is just built wrong… it’s not a wizard, it is a series of tabs vertically arranged. You are going to see this image many many times before you get to grips with this layout.

  • And then you are going to click SAVE and get out of the Wizard rather than going to the next screen many many times.

  • You get to here then you wait. Then you will not wait, then you will have to start again. Why is is field lookup dialog so BAD and so SLOW!

  • The Edit button is in a weird and inconvenient location. Why can’t I click on the name or click an edit link next to the name.

Creating a Test

  • Know your data first… have a record handy that meets all the criteria that you want to be testing

  • Know the fields you want to work with - you will need to use ctrl+f to find them on the page layout.

  • Have two screens, one with your actual record, one with the Flow Testing… you can not work out what is going on in the flow testing screen - just don’t even try.

  • Take a screen shot of your variable updates or record updates so you know what you need to reference when building your assertions.

  • There are 3 approaches - I like the first one

    • Pick a completed record, clear out the values for the Initial Triggering Record

    • Pick a basic records, add values for the Updated Triggering Record

    • Create a Test from a Debug

  • BUT, you don’t even need to do that at all! just DON’T use a Triggering Record. The link to the record is NOT saved at all, so a LOT of extraneous data is just going to be copied into your test. Just fill in the key fields that are needed for this test and ignore the rest. And this is WAY better than storing sensitive data in tests!

Question

  • So, you want to create a test on an object where records go through a set process - eg Cases going from new to Triage, to Open to Closed… you need a test record for a New Case, but immediately after saving that test that record may not be new anymore? Will the test still work?

    • Yes - don’t use actual records as your test setups, just enter the data directly.

  • You create a test and you have to hard code the values, and then during the regular course of the business that record has that value changed… does it break the flow test, or is that record copied forever in that state that it was at at the time you created the test?

    • No - don’t use actual records as your test setups, just enter the data directly.

Other Notes