Skip to content
Namaste Salesforce Namaste Salesforce
Developer Roadmap

Testing to 75%

Apex requires 75% test coverage to deploy — but write tests that assert real behaviour, not just chase a number.

Developer Roadmap Article 1 min

Testing to 75%

Salesforce will not let you deploy Apex to production unless your org has at least 75% code coverage and all tests pass. That rule exists to protect a shared, multitenant platform, but treating coverage as the goal produces brittle, useless tests. The real goal is tests that assert behaviour — they should fail when the code does the wrong thing, and coverage is a side effect of doing that thoroughly.

Test classes are annotated with @isTest and, by default, are isolated from your org's data — a test cannot see existing records and must create its own. This is a feature: it makes tests deterministic. You wrap the code under test between Test.startTest() and Test.stopTest(), which also gives fresh governor limits and forces any queued async work to run.

@isTest
private class AccountTriggerHandlerTest {
    @isTest
    static void defaultsRatingOnInsert() {
        // Given: an account with no rating
        Account a = new Account(Name = 'Acme');

        // When: it is inserted (fires the trigger)
        Test.startTest();
        insert a;
        Test.stopTest();

        // Then: the handler set a default — assert the real behaviour
        Account result = [SELECT Rating FROM Account WHERE Id = :a.Id];
        System.assertEquals('Warm', result.Rating, 'Rating should default to Warm');
    }
}

Write tests that cover three situations: the positive path (correct input produces the expected result), negative paths (bad input is rejected, exceptions are thrown), and bulk (insert 200 records to prove the code is bulk-safe and stays within limits). Always include meaningful System.assert calls; a test with no assertions gives coverage but verifies nothing.

Use a test data factory — a reusable class that builds valid records — so tests stay short and consistent, and use @testSetup to create shared data once per class. Avoid seeAllData=true except when unavoidable, because it makes tests depend on org state.

As an exercise, write a test for the trigger handler from the previous lesson covering the single-record and 200-record cases, with real assertions, and confirm coverage exceeds 75%. Solid tests are what let you refactor and deploy with confidence. With Apex covered, the next section moves to the front end with Lightning Web Components.

Advertise with us · 728×90