Salesforce Apex Testing

You are a Salesforce Apex developer. The user wants to write test classes with test data factories and assertions to meet Salesforce's 75% code coverage requirement and ensure reliable test execution.

What to check first

• Run sfdx force:apex:test:run -u [username] to see current test results and coverage
• Verify @isTest annotation is present on test class and test methods
• Check that test data setup uses @testSetup method for shared data across test methods

Steps

1. Create a test data factory class with @isTest annotation and static methods that return SObjects (e.g., static Account createTestAccount(String name))
2. In your test class, use System.runAs(new User(Id=[testUserId])) to enforce Field-Level Security and sharing rules during tests
3. Add the @testSetup static method to create data once per test class execution, reducing DML statements
4. Use Test.startTest() and Test.stopTest() to isolate governor limit consumption and async operations
5. Call your factory methods within @testSetup to instantiate test records (Accounts, Contacts, Opportunities, custom objects)
6. Write individual test methods with clear naming: testMethodName_ExpectedBehavior_Condition
7. Use System.assertEquals(), System.assertNotEquals(), and System.assert() for assertions on record fields and method return values
8. Insert test data using insert statement before calling the method under test, ensuring proper governor limits tracking

Code

@isTest
public class OpportunityTestFactory {
    public static Account createTestAccount(String name) {
        Account acc = new Account(Name = name);
        return acc;
    }
    
    public static Opportunity createTestOpportunity(Id accountId, String stageName) {
        Opportunity opp = new Opportunity(
            Name = 'Test Opp',
            AccountId = accountId,
            StageName = stageName,
            CloseDate = Date.today().addDays(30)
        );
        return opp;
    }
}

@isTest
public class OpportunityTriggerTest {
    @testSetup
    static void setupTestData() {
        Account testAcc = OpportunityTestFactory.createTestAccount('Test Company');
        insert testAcc;
        
        Opportunity testOpp = OpportunityTestFactory.createTestOpportunity(
            testAcc.Id,
            'Prospecting'
        );
        insert testOpp;
    }
    
    @isTest
    static void testOpportunityStageChange_UpdatesAccountField_WhenClosedWon() {
        Test.startTest();
        
        Opportunity opp = [SELECT Id, StageName FROM Opportunity LIMIT 1];
        opp.StageName = 'Closed Won';
        update opp;
        
        Test.

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change