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
No database records are harmed during this testing! Just like debugging, nothing is saved to the database… this is good.
You can’t be building these tests in a Sandbox with data that is not 100% like production.
How do you even Deploy Flow Tests then?
You can’t Google Flow Tests and find anything about these tests…
In the Release Readiness Live they mentioned something about the Error Message and it sort of looked like for a second there that they had fixed the issue with Error Messages on Flows (see Flow Validations), but it did make for some good Twitter Discussion.
The Good
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.
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?
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?
Other Notes