Testing Apex

Salesforce will not let you deploy Apex to production unless your tests cover at least 75% of your Apex lines and all tests pass. But coverage is only a number. The real purpose of a test is to prove your code does what you think, for one record and for 200, so you can change it later without fear.

In this tutorial you will write a test class for the Opportunity trigger from the previous lesson, covering the happy path, the error path and a bulk case. You will then run it and read the coverage.

Prerequisites: *Apex triggers and governor limits* (you need OpportunityTrigger and OpportunityTriggerHandler saved in your org) and *Apex basics*.

Create the class in the Developer Console with File > New > Apex Class, name it OpportunityTriggerTest. A common layout is: a @TestSetup method that creates shared data once, a small helper to build records, and one test method per behaviour.

@IsTest
private class OpportunityTriggerTest {

    @TestSetup
    static void setup() {
        Account acc = new Account(Name = 'Test Cafe');
        insert acc;
    }

    // Builds (but does not save) opportunities for the test account
    private static List<Opportunity> buildOpps(Integer howMany) {
        Account acc = [SELECT Id FROM Account WHERE Name = 'Test Cafe' LIMIT 1];
        List<Opportunity> opps = new List<Opportunity>();
        for (Integer i = 0; i < howMany; i++) {
            opps.add(new Opportunity(
                Name = 'Deal ' + i,
                AccountId = acc.Id,
                StageName = 'Prospecting',
                CloseDate = Date.today().addDays(30),
                Amount = 1000
            ));
        }
        return opps;
    }

    // test methods go here
}

The class is private because only the test runner uses it. @TestSetup runs once and its data is available to every test method; each method gets a fresh copy because changes are rolled back between methods.

Note the required fields: an Opportunity needs a Name, a StageName and a CloseDate. Missing one makes your test fail before the trigger even runs. Add other required fields if your org has custom validation rules or required fields.

A good test follows Arrange, Act, Assert: set up data, do the thing, check the result. Use the Assert class (Assert.areEqual, Assert.isTrue, Assert.isNull and others) with a message that says what went wrong. Older code uses System.assertEquals; it still works but Assert gives clearer failures.

    @IsTest
    static void createsFollowUpTaskWhenWon() {
        List<Opportunity> opps = buildOpps(1);
        insert opps;

        Test.startTest();
        opps[0].StageName = 'Closed Won';
        update opps;
        Test.stopTest();

        Id oppId = opps[0].Id;
        List<Task> tasks = [
            SELECT Id, Subject FROM Task WHERE WhatId = :oppId
        ];
        Assert.areEqual(1, tasks.size(), 'One task should be created');
        Assert.areEqual('Send onboarding email', tasks[0].Subject);
    }

Creates an open opportunity, moves it to Closed Won, and checks exactly one Task was created with the right subject.

Test.startTest() and Test.stopTest() wrap the code you are actually testing. They give that block its own fresh set of governor limits, so the data setup before it does not eat into the limits you are measuring. Test.stopTest() also waits for any asynchronous Apex you started (Queueable, future methods) to finish, so you can assert on its results afterwards.

Good tests also prove that bad input is rejected. To check that addError blocks a save, use Database.insert(record, false) so the test does not crash, then inspect the result.

    @IsTest
    static void blocksClosedWonWithoutAmount() {
        Opportunity opp = buildOpps(1)[0];
        opp.StageName = 'Closed Won';
        opp.Amount = null;

        Test.startTest();
        Database.SaveResult result = Database.insert(opp, false);
        Test.stopTest();

        Assert.isFalse(result.isSuccess(), 'Save should be blocked');
        String message = result.getErrors()[0].getMessage();
        Assert.isTrue(message.contains('greater than zero'), 'Unexpected message: ' + message);
    }

    @IsTest
    static void dmlExceptionIsThrownWhenNotUsingDatabaseClass() {
        Opportunity opp = buildOpps(1)[0];
        opp.StageName = 'Closed Won';
        opp.Amount = 0;

        try {
            insert opp;
            Assert.fail('Expected a DmlException');
        } catch (DmlException e) {
            Assert.isTrue(e.getMessage().contains('greater than zero'));
        }
    }

Two ways to test a failure: look at the SaveResult, or expect a DmlException. Assert.fail makes the test fail if no exception was thrown.

This is the test that proves bulkification. Insert 200 opportunities, move all to Closed Won, and confirm 200 tasks. If your handler had a query or DML inside the loop, this test would fail with a limit error.

    @IsTest
    static void handlesTwoHundredRecords() {
        List<Opportunity> opps = buildOpps(200);
        insert opps;

        for (Opportunity opp : opps) {
            opp.StageName = 'Closed Won';
        }

        Test.startTest();
        update opps;
        Test.stopTest();

        Set<Id> oppIds = new Map<Id, Opportunity>(opps).keySet();
        Integer taskCount = [SELECT COUNT() FROM Task WHERE WhatId IN :oppIds];
        Assert.areEqual(200, taskCount, 'Each opportunity should get one task');
    }

    @IsTest
    static void doesNotCreateTasksForOtherStageChanges() {
        List<Opportunity> opps = buildOpps(2);
        insert opps;

        opps[0].StageName = 'Qualification';
        update opps;

        Set<Id> oppIds = new Map<Id, Opportunity>(opps).keySet();
        Integer taskCount = [SELECT COUNT() FROM Task WHERE WhatId IN :oppIds];
        Assert.areEqual(0, taskCount, 'Only Closed Won should create tasks');
    }

The first test checks 200 records in one transaction. The second checks that a different stage change creates nothing, which guards against the logic firing too often.

Running as another user. System.runAs(user) runs a block as a specific user, so you can test sharing and permissions. Create a user with a profile query and unique values, and wrap only the code you need in runAs. Remember that test data you create is still rolled back.

If a line shows red, ask: which behaviour does that line implement? Write a test for the behaviour rather than just touching the line. Chasing 75% by calling methods with no assertions satisfies the rule but not the purpose.

When many test classes need accounts and opportunities, repeat yourself less with one shared @IsTest utility class, often named TestDataFactory. Keep it small: methods that return built (and optionally inserted) records with valid defaults. When a required field is added to an object later, you fix it in one place.

@IsTest
public class TestDataFactory {
    public static Account createAccount(String name, Boolean doInsert) {
        Account a = new Account(Name = name);
        if (doInsert) {
            insert a;
        }
        return a;
    }
}

Because the class is marked @IsTest it cannot be used by production code, which is intended.

Testing callouts. Tests cannot make real HTTP calls. You write a class implementing HttpCalloutMock that returns a fake response, and tell the test about it with Test.setMock(HttpCalloutMock.class, new MyMock());. You will use this in *Integration: REST APIs and platform events*.

How this comes up in interviews. Common questions: what is the minimum coverage and what else is required (75% overall, all tests pass, triggers need some coverage); what @TestSetup does; why use startTest and stopTest; what SeeAllData does and why avoid it; how to test a trigger with 200 records; how to test a callout; and how System.runAs works.

You are a Salesforce developer who writes high-quality Apex tests. Write a test class for the Apex class below. Use @TestSetup for shared data, Assert class methods with messages, one happy path, one negative path and one bulk test with 200 records, and Test.startTest/stopTest around the code under test. Do not use SeeAllData.

[paste Apex class or trigger]

What to expect: A good answer builds its own data with all required fields, asserts actual outcomes (not only that no error occurred) and includes the 200-record test. Run it in your org: AI-written tests often miss a required field or a validation rule.