1

I'm working with a custom process flow in which the system should update a relationship. With that said, I think it is pretty obvious that the Ids differ from the sandbox and the production environments, and of course it is different on the test classes context.

Some flows have formula criterias. Is there a way not to run those flows in a test context? Something like ISTEST() on formula? I know that we have that on Apex, but I've never seen it on process builder.

If not available, what would be an acceptable approach in this situation, so the flow wouldn't mess up the tests?

2
  • You should avoid using hard-coded ID values if possible (and usually this is possible). Can you provide a specific scenario that you're trying to avoid?
    – sfdcfox
    Commented Feb 5, 2018 at 18:20
  • Use case is that the customer wants that when an account is created it is immediately associated with another specific account. Commented Feb 5, 2018 at 18:21

2 Answers 2

1

You should not be using a hard-coded ID value, when possible. Further, you have no way of knowing if you're in a unit test within a Process Builder, aside from setting up a custom mechanism (such as setting a value in a UI-hidden field). The Process Builder itself is pretty limited in this regard; it's the same reason why you wouldn't ordinarily want to use a Workflow Rule to do this. Ideally, you should simply use a trigger for this, because you'll want to be able to query the account. You can also use an auto-launched flow to query the record, but be aware that calling this bulk will drastically degrade performance and risks running in to governor limits. For now, any time you need a specific record by ID, your best option is still writing a trigger.

4
  • I really think an ISTEST() formula function would be useful right now. :( Commented Feb 5, 2018 at 18:46
  • @RenatoOliveira I would disagree with that statement. Doing do makes your code untestable, which means that the day someone decides to accidentally delete the account, the client will be dead in the water until they fix the process builder. At least with a unit test, you can verify that the behavior is not broken. You should test both "when the account exists" as well as "when the account does not exist."
    – sfdcfox
    Commented Feb 5, 2018 at 18:56
  • My reasoning in this case is that it would be much easier to fix (or disable) a process than an Apex class for a customer with no background in programming. Commented Feb 5, 2018 at 19:04
  • I know this very old post, But it I found a solution, create as below
    – jks
    Commented Nov 3 at 21:26
0

I found a solution, create Invocable method and call in action element in flow and then verify and skip the element if it is true, here is the code

public with sharing class TestHelper {

@InvocableMethod
public static List<Boolean> IsTestExecuting(){
    List<Boolean> output = new List<Boolean>();
    output.add(Test.isRunningTest()); 
    return output;
}

} and then assign output a variable in the flow and check for true and then take an action.

1
  • The original question centers on a solution using the declarative approach, and I even said "I know that we have that on Apex" in my original question, but I can see how this answer might help others with a similar - not the same - situation. Your code works if the flow runs with a single element, but won't it fail if it is invoked by a record-triggered flow that runs with multiple records on the same transaction? Nevertheless, thank you for the contribution. Commented Nov 4 at 18:45

You must log in to answer this question.

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