Learn how governor limits affect Apex test classes. Master DML, SOQL, CPU, heap, and callout limits with bulk-safe testing patterns.
# Governor Limits in Apex Testing: A Complete Guide
Salesforce governor limits don’t disappear in tests-they’re enforced to keep code scalable and predictable. That makes understanding **governor limits in Apex testing** essential for writing reliable, bulk-safe test classes that pass in any org (including those with heavy automation, large metadata footprints, and strict CPU constraints).
This guide explains the most important limits (DML, SOQL, CPU time, heap size, callouts, and more), how they behave in test context, and how to design **Apex test classes** that are bulk-safe and resilient. You’ll also see practical patterns and examples you can use immediately.
## Why Governor Limits Matter in Apex Test Classes
Apex is multi-tenant. Governor limits enforce fairness and ensure your code can run at scale. Tests have two jobs:
1. **Prove correctness** (assertions and expected outcomes)
2. **Prove scalability** (bulk safety, efficient queries, minimal DML, and stable performance)
A test class that “works” but blows limits in edge cases is a future production incident waiting to happen.
### Do Tests Have Different Limits?
Some limits are higher or behave differently during tests, but the core concept remains: you can still hit limits, especially:
- **SOQL query limits** (e.g., too many queries due to loops)
- **DML limits** (e.g., one DML per record)
- **CPU time** (e.g., heavy loops, regex, JSON parsing, or runaway triggers)
- **Heap size** (e.g., building large in-memory structures)
In tests, you also have special tools like `Test.startTest()` and `Test.stopTest()` to reset certain limits and control asynchronous execution.
## Key Governor Limits to Watch in Apex Testing
Below are the limits most likely to cause fragile test classes. (Exact numeric values can vary by context; always confirm with Salesforce documentation and your org behavior.)
### DML Limits in Apex Tests
**DML statements** are limited per transaction. If your code performs DML inside loops, you can easily exceed limits-especially when triggers, flows, and managed packages add extra work.
**Common anti-pattern (DML in a loop):**
```apex
for (Account a : accounts) {
a.Description = 'Updated';
update a; // DML inside loop
}
```
**Bulk-safe pattern (single DML):**
```apex
for (Account a : accounts) {
a.Description = 'Updated';
}
update accounts; // one DML
```
#### Testing DML Bulk Safety
Your test should exercise the bulk path, not just single-record behavior.
- Insert a list of records (e.g., 50–200 depending on logic)
- Call the method/trigger once
- Assert outcomes across multiple records
Example:
```apex
@IsTest
private class AccountServiceTest {
@IsTest
static void testBulkUpdateIsBulkSafe() {
List<Account> accts = new List<Account>();
for (Integer i = 0; i < 100; i++) {
accts.add(new Account(Name = 'A-' + i));
}
insert accts;
Test.startTest();
AccountService.bulkUpdateDescriptions(new Set<Id>(new Map<Id,Account>(accts).keySet()));
Test.stopTest();
List<Account> updated = [SELECT Id, Description FROM Account WHERE Id IN :accts];
for (Account a : updated) {
System.assertEquals('Updated', a.Description);
}
}
}
```
This pattern helps ensure your **Apex testing** covers real-world data volumes.
### SOQL Limits in Apex Test Classes
**SOQL queries** are limited per transaction. The most common reason test classes fail in large orgs is not the test itself, but the code under test issuing too many queries due to:
- Queries inside loops
- Re-querying the same records repeatedly
- Trigger recursion patterns
**Anti-pattern (SOQL in a loop):**
```apex
for (Id accId : accountIds) {
Account a = [SELECT Id, Name FROM Account WHERE Id = :accId];
}
```
**Bulk-safe pattern (single query):**
```apex
Map<Id, Account> accMap = new Map<Id, Account>([
SELECT Id, Name
FROM Account
WHERE Id IN :accountIds
]);
```
#### Testing SOQL Efficiency
You can’t always assert “number of queries” directly without over-coupling tests to implementation, but you *can*:
- Structure tests to push bulk paths (e.g., 200 records)
- Avoid unnecessary test-side queries (use `@testSetup` and reuse data)
- Ensure the service layer accepts IDs/lists and performs a single query
When you do need visibility during development, `Limits.getQueries()` can help diagnose issues. Use it sparingly; don’t make tests brittle by asserting exact query counts unless that’s the requirement.
### CPU Time Limits in Tests
**CPU time** is a frequent source of failures in enterprise orgs with:
- Complex trigger frameworks
- Heavy validation logic
- Multiple automations (Flow, Process Builder legacy, managed packages)
In tests, CPU spikes often come from:
- Large loops with per-iteration work
- String concatenation in loops
- Regex evaluation on big payloads
- JSON serialize/deserialize on large objects
#### How to Reduce CPU in Code and Tests
- Prefer maps/sets for lookups (`Map<Id, SObject>`) over nested loops
- Avoid repeated computations inside loops
- Batch operations (one query, one DML)
- Use selective queries and only retrieve fields you need
**Example: replacing nested loops with a map**
```apex
Map<Id, Account> byId = new Map<Id, Account>(accounts);
for (Contact c : contacts) {
Account parent = byId.get(c.AccountId);
if (parent != null) {
c.Description = parent.Name;
}
}
```
### Heap Size Limits
The heap is your in-memory footprint. Tests can hit heap limits when they:
- Build massive lists of SObjects or large strings
- Load large blobs or attachments
- Deserialize large JSON payloads
#### Heap-Safe Testing Tips
- Don’t generate huge payloads unless necessary for the scenario
- Prefer querying only required fields
- Use streaming patterns where possible (in production code)
- In tests, validate behavior with minimal representative data, then separately test “large volume” with smaller payloads that still exercise the logic
### Callout Limits and Callouts in Tests
Apex callouts are restricted, and tests can’t make real callouts. In **Apex testing**, you must use mocks.
Key points:
- Use `Test.setMock(HttpCalloutMock.class, new MyMock())`
- Use `Test.startTest()` / `Test.stopTest()` to ensure async callouts execute
Example mock:
```apex
@IsTest
global class ExampleCalloutMock implements HttpCalloutMock {
global HTTPResponse respond(HTTPRequest req) {
HttpResponse res = new HttpResponse();
res.setStatusCode(200);
res.setBody('{"success":true}');
return res;
}
}
```
Example test:
```apex
@IsTest
private class IntegrationServiceTest {
@IsTest
static void testCalloutWithMock() {
Test.setMock(HttpCalloutMock.class, new ExampleCalloutMock());
Test.startTest();
Boolean ok = IntegrationService.performCallout();
Test.stopTest();
System.assertEquals(true, ok);
}
}
```
This ensures your tests are stable across orgs and CI pipelines.
## Writing Bulk-Safe Tests That Pass in Any Org
The best defense against governor limit failures is to write tests that:
- Are **bulk-aware**
- Minimize test-side overhead
- Don’t assume a “clean org”
### Use `@testSetup` to Reduce Redundant DML
`@testSetup` runs once per test class and creates records shared across test methods (with isolation). This reduces repetitive DML and CPU across multiple tests.
```apex
@IsTest
private class OrderServiceTest {
@testSetup
static void setup() {
List<Account> accts = new List<Account>();
for (Integer i = 0; i < 50; i++) {
accts.add(new Account(Name = 'Setup-' + i));
}
insert accts;
}
@IsTest
static void testSomething() {
List<Account> accts = [SELECT Id FROM Account WHERE Name LIKE 'Setup-%' LIMIT 50];
// ...
}
}
```
### Always Test Collections, Not Singles
If your production method signature accepts a single Id, consider overloading it (or refactoring) to accept a set/list and delegate to the bulk method. Then test the bulk method.
Recommended pattern:
- `doWork(Set<Id> ids)` (bulk entry)
- `doWork(Id id)` calls `doWork(new Set<Id>{id})`
### Place `Test.startTest()` / `Test.stopTest()` Intentionally
These calls:
- Reset certain governor limits for the code executed inside the block
- Help isolate the “unit under test” from heavy test setup
- Ensure async jobs (Queueable/Future) run on `stopTest()`
Pattern:
1. Create data (outside start/stop)
2. `Test.startTest()`
3. Call method under test
4. `Test.stopTest()`
5. Query and assert results
### Avoid Brittle Tests That Depend on Org Data
Even though `SeeAllData=true` exists, avoid it unless you have a specific reason. It makes tests:
- Slower
- Less predictable
- More likely to fail in sandboxes and scratch orgs
Instead, create the minimum data you need in the test.
### Understand Automation Side Effects
In many orgs, inserting “simple” records triggers:
- Flows
- Validation rules
- Managed package triggers
- Rollups and sharing recalculations
Your test data factory should create valid records that satisfy required fields and common validations. Keep it minimal but realistic.
## Practical Examples: Diagnosing Governor Limits in Tests
### Example 1: Too Many SOQL Queries from Trigger Logic
Symptoms:
- Tests fail only when you insert many records
- Error: “Too many SOQL queries: 101”
Fix approach:
- Search for SOQL inside loops in triggers/handlers
- Move queries out of loops
- Query all necessary records once and use maps
### Example 2: CPU Timeouts in Large Orgs
Symptoms:
- Tests pass in a dev org but fail in UAT/Full Copy
- Error: “Apex CPU time limit exceeded”
Fix approach:
- Reduce nested loops; replace with map lookups
- Remove repeated string operations in loops
- Ensure triggers are bulkified and guarded against recursion
- Use `Test.startTest()` to isolate the method under test from setup CPU
### Example 3: Callout Tests Failing in CI
Symptoms:
- Error: “Methods defined as TestMethod do not support Web service callouts”
Fix approach:
- Add `HttpCalloutMock`
- Ensure the code path uses `Http.send()` only after mock is registered
- Wrap async callout initiation inside `Test.startTest()` / `Test.stopTest()`
## A Governor-Limit-Aware Checklist for Apex Testing
Use this checklist to keep your **Apex test classes** reliable:
- **Bulk test coverage**: test with 50–200 records where relevant
- **No DML in loops** in production code under test
- **No SOQL in loops** in production code under test
- Use **`@testSetup`** to reduce repeated DML
- Use **`Test.startTest()` / `Test.stopTest()`** to isolate and execute async
- Mock all **callouts** with `HttpCalloutMock`
- Keep test data **minimal but valid** (avoid SeeAllData)
- Prefer **maps/sets** for performance and CPU safety
- Don’t assert brittle internals (like exact query counts) unless required
## Conclusion: Build Limit-Resilient Tests (and Ship Faster)
Governor limits are not just a production concern-**governor limits in Apex testing** directly determine whether your deployments and CI pipelines stay green as your org grows. By writing bulk-safe code, designing bulk-safe tests, and deliberately managing SOQL, DML, CPU time, heap size, and callout constraints, you create test suites that are stable in any org.
If your team is spending too much time writing and maintaining Apex test classes, **Apex AI** helps Salesforce engineering teams generate high-quality Apex test classes faster-while keeping best practices like bulk safety and limit-aware design front and center. Explore Apex AI to accelerate coverage without sacrificing scalability.