You may have to limit the number of records you create, even down to one per type. If it's still hitting the limit at that point, you're pretty much SOL. As a last resort, you can use SeeAllData=true
so that you aren't hitting triggers. Test.loadData
won't really help as it still fires triggers.
One solution you can implement as you build out your org (which may be more difficult to implement with existing functionality) is to build trigger stop flags into your handler pattern. My template looks something like:
public with sharing class LeadTriggerHandler
{
@TestVisible static Boolean bypassTrigger = false;
final List<Lead> newRecords;
final Map<Id, Lead> oldMap;
public LeadTriggerHandler(List<Lead> newRecords, Map<Id, Lead> oldMap)
{
this.newRecords = newRecords;
this.oldMap = oldMap;
}
public void beforeInsert()
{
if (bypassTrigger) return;
//LeadSerivices.method1(newRecords);
}
public void afterInsert()
{
if (bypassTrigger) return;
//LeadSerivices.method2(newRecords);
}
public void beforeUpdate()
{
if (bypassTrigger) return;
//LeadSerivices.method1(newRecords);
}
public void afterUpdate()
{
if (bypassTrigger) return;
//LeadSerivices.method3(newRecords);
}
}
Then in your test you can just do:
LeadTriggerHandler.bypassTrigger = true;
insert new Lead(/*data*/);
LeadTriggerHandler.bypassTrigger = false;
This flagging strategy can dramatically streamline your tests, and can be implemented in a variety of ways. The key is that the flag is static
, though I think it is important to keep it private
if at all possible.
I've heard many people asking similar questions with the same issue.
This is a bug with the displayed code coverage but will not be factored into minimum coverage deployment calculations.
This is most likely caused by initially creating/saving your test factory class without the @isTest prefix. If you follow these instructions you can remove the incorrect data. Then when you rerun tests it should not reappear.
Best Answer
As I have just rewritten our internal unit test design patterns I've tested this quiet thoroughly and believe I have a proper grasp on how
@testSetup
currently handles governing limits within the test classIn short, any DML statement within the context of
@testSetup
will not count against your overall test class limits but SOQL statements will.For example:
The above
INSERT
on Accounts will have no influence on your governing limit in of itself but the SOQL statement will count as 1.NOTE: If your org has events that are triggered from that
INSERT
(which you likely do), THEN any DML or SOQL statement that proceeds from those are considered outside the context of@testSetup
and will impact your overall governing limits for your test class.As always these limits are reset within any test method when you invoke
Test.startTest();
andTest.stopTest();
but this could affect how much data you can setup within your data setup method (for example when cascading dependencies like Contacts, which need Accounts).If you have a WFR on Leads that will INSERT an Activity based on certain criteria, then the INSERT of that Activity will not affect your limits but again if it triggers any DML/SOQL then expect it to impacting your limits
Because I have foundation test classes that cover a majority of the essential trigger context for every object I wanted to include as much data as necessary for certain test classes, but unfortunately I would run into limit issues quickly because of triggers. So thankfully, since we use Kevin O'Hara's TriggerHandler Framework, we were able to implement his handy
bypass()
method which temporarily pauses all trigger activity within your TriggerHandler classFor example:
Hope this proves to be useful in someone, feel free to comment with any adjustments you believe are necessary to this explanation.