I hope this is not a foolish question but would there be any value to writing test classes for Flows and Process Builder? Not to check code coverage but to use assertions. I am starting to get better on the programmatic side of things and wondering if a Test Class that uses system.assertequals on Processes and Flows would help to ensure that they are doing what they are supposed to?

3 Answers 3


Here's my take.

You write "Test Classes" to Unit Test your custom "Apex Class" which in turn performs some business logic, updates some records, etc written in your "Apex Class". You use System.assert to perform assertions on the outcomes after what your code would have operated on a record. And that most importantly you also need a "Test Class" because your custom code needs coverage before deployment to Production.

Now, Process Builder is just a point-and-click tool to automate your Business Process in another way. But it ultimately performs on a record. So if you want to use System.assert, that would mean that you are still performing assertions on the outcomes of the process builder.

While you would have ideally performed unit tests, qa/uat tests which would have confirmed your Process Builder outcomes, but if at all you want to extend this by writing Test Classes, I would think you can still do that. Say you have a Process Builder where after you insert a record on object A, it updates XYZ field on a record of object B. So that way you can create two records in your test class and thus perform those assertions.

So in general, you can still write test classes not specifically on the "type of tool" you are using (apex, process builder, validation rules, workflow, etc.) but instead to test what and how your records perform and that if that meets the expected scenario.

  • I would argue that any organization that make use of PB needs to also write tests for it. Even though your test don't need to focus on some lower level issues (bad SOQL queries as an example). PB still manipulate records. PB can include some reasonably complex logic that should be tested to ensure it works as expect. The biggest issues is that doing Unit Testing with BP is much harder rather then looking at it more along the lines of Integration Testing. If you have multiple PB rules that impact the same records then your bound to run into bugs.
    – John
    Sep 21, 2018 at 17:36
  • Agreed. And my point is that you actually don't write test cases for PB, but around the outcomes of PB on a record. Its not the "tool" but the end result that its performing and ultimately its the record in consideration.
    – Jayant Das
    Sep 21, 2018 at 17:43

The ability to write tests for flows are relatively limited, simply because the flow engine can't be easily manipulated from Apex. While one might argue that there is some benefit to such a test, without a way to properly inspect the state of the flow like we can with @TestVisible, I suspect that most flows wouldn't be easily testable without exposing variables unnecessarily, which would clutter the UI when you're using flows in processes, etc. If you wanted to spend the time doing this, I would say it wouldn't hurt anything, I'm just not convinced you'd get any benefit out of it.

For Process Builder, though, you could indeed write tests to make sure the logic works. This also helps prevents things like forgetting to deploy the process, activating the process, making sure your business logic is enforced, etc. I wouldn't spend a lot of time on such tests, but I can definitely see the value in doing so. I do know that sometimes Process Builder behaves oddly in unit tests, though, so this might also cause false positives as well.


The value of unit tests for declarative automations (PB, Flow, and Workflow Rules) is probably highest if you use continuous integration pervasively, not just for your Apex code. Even though the behavior of those declarative automations is usually pretty easy to document through simple UI interactions, they can interact in interesting ways with your code, each other, and simple declarative customizations like validation rules and lookup field filters.

If you introduce a new validation rule, for example, and run all your unit tests, you'll immediately know which Apex classes or tests are impacted by the change. If you've written unit tests for your declarative automation too, you can catch problems there before you have to go all the way to UAT, which can cut the length of the testing cycle way down.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .