Is there anything built into Apex that lets one perform a CRUD operation on an SObject and suppress the related firing of any Apex Trigger / Workflow Rule / Process Flow?

(Similarly to the way one can spoof a create date, spoof the run-as user, etc.)

I've written some "helper" code to support a variety of trigger handlers. Since this code is called from the various trigger handlers, it actually has pretty good coverage without even trying to test it in a "pure" fashion.

But I'd like to give it its own test - that way, I know if my "helper" code actually does what I think it does, plus I can turn off triggers and still have coverage.

To exercise the "helper" code, some test records of the types it deals with have to exist. So my new test class has to insert them into the database.

However, that means I'll be invoking the triggers on all those SObject types, making it hard to tell just how much my new code is directly responsible for working the "helper class."

I suppose I could turn those triggers off for a few hours while I write the new test class, but that's annoying - and feels less cool.


1 Answer 1


Out of the box? No. But there are a few strategies you can implement. The simplest for triggers (and what I use) is to add a bypass flag in each handler.

public with sharing class MyTriggerHandler
    @TestVisible static Boolean bypassTrigger;

    public void beforeInsert()
        if (bypassTrigger) return;

        // do stuff

I have one handler per object, so it's pretty simple in my tests.

static testMethod void testSomething()
    AccountTriggerHandler.bypassTrigger = true;
    // insert accounts
    AccountTriggerHandler.bypassTrigger = false;

    ContactTriggerHandler.bypassTrigger = true;
    // insert contacts
    ContactTriggerHandler.bypassTrigger = false;

You can add granularity (at the cost of complexity) to taste with this pattern. For your needs, it sounds like a top level flag is ample.

A common strategy for Workflow Rule or Process Builder is to add a dummy checkbox that you can uncheck to disable them. Then in each, you have to make sure the criteria include NOT(Checkbox__c). I would have reservations about such a strategy if someone wanted me to implement it though, and seek workarounds specific to the situation.

  • 2
    Okay, good to know. So for today, I either have to edit my triggers twice (once turning off, once turning back on) or once (adding your code). Can't be totally lazy. :-) Thanks as always!
    – k..
    May 20, 2016 at 16:22
  • @k.. You can call it bookends or use it as a verb, even. I'm not sure I follow your once/twice distinction.
    – Adrian Larson
    May 20, 2016 at 16:24
  • Just jokingly lamenting that I had to be a LITTLE not-lazy and at least open all my triggers in the editor!
    – k..
    May 20, 2016 at 16:35
  • 1
    Ah yes. Thankfully it is pretty simple to integrate into most patterns. :)
    – Adrian Larson
    May 20, 2016 at 16:35

You must log in to answer this question.

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