CPU Limit While Inserting Contact Records Via Test Class - Workaround?

Question

I'm writing my first batch class -- it looks for existing Contact records where AccountId is the Id of a dummy account and where the value in Company_Plain_Text_Field__c is a string-match to any existing Account.Name field in the database.

I've been writing a test class and have the logic good, and now I want to stress-test it.

The problem is that our org is so overloaded with nasty triggers on Contact that I can't even run this code to lay down test data without a CPU Limits error (I know it's this, because I commented out the part of the test class that was actually invoking the batch class):

for (Integer i = 0; i < 3000; i++) {
    cs.add(
        new Contact(
            AccountId=defaultDummyAccountId, 
            LastName='xyzzy', 
            Company_Plain_Text_Field__c='stringIKnowIsARealAccountName'
        )
    );
}
INSERT cs;

(It works fine with i < 1000; I haven't found the exact breakpoint.)

Is there anything I can do to get a bunch of Contact records into the world of the test despite our fragile Contact triggers -- maybe simulate a batch INSERT of Contact -- so I can really stress-test the UPDATE behavior of the class I'm actually trying to design?

Answer 1

When you're designing your own triggers, this sort of scenario is something you can plan ahead for. My typical trigger handler pattern looks something like the following:

public with sharing class MyObjectTriggerHandler
{
    @TestiVisble static Boolean bypassTrigger = false;
    final List<MyObject__c> newRecords;
    final Map<Id, MyObject__c> oldMap;
    public MyObjectTriggerHandler(newRecords, Map<Id, MyObject__c> oldMap)
    {
        this.newRecords = newRecords;
        this.oldMap = oldMap;
    }

    public void beforeInsert()
    {
        if (bypassTrigger) return;
        // event specific logic below
    }
}

That way, in my tests, it is quite simple to bypass the trigger completely:

ContactTriggerHandler.bypassTrigger = true;
insert bulkContacts;
ContactTriggerHandler.bypassTrigger = false; // don't forget to bookend!

Now whether or not it is feasible to incorporate something similar in your existing triggers is unclear. But without some mechanism similar to the above, you're pretty much stuck letting the triggers execute and only inserting as many records as you can get away with. Moving setup into a @TestSetup method may help mitigate the consumption somewhat.

Answer 2

If you're doing 3000 contacts, you're not creating a unit test. Your unit test can at most process 200 records at a time (a single batch). If you were to need more data that your existing triggers were causing issues with, you could potentially use Test.loadData where you load your data from a CSV file. Stress testing is something you presumably would want to do in a Partial Sandbox. See the Trailhead Module on Application Lifecycle Management.