Learning progress is unavailable. Reading and direct practice remain available; completion controls are disabled.

Lesson 4 of 6 · 5–10 minutes including the walkthrough and reflection

Apex Testing

Apex tests are not just a deployment checkbox. Good tests explain the behavior your code promises, catch regressions, and give reviewers confidence that the implementation works for real Salesforce data shapes.

The concept

A useful Apex test usually follows this shape: Arrange Create the data the behavior needs. Act Run the code path you want to verify. Assert Query or inspect the observable result and prove it matches the requirement. Coverage tells you which lines executed. Assertions tell you whether the behavior was correct. A strong test suite includes: - positive cases: expected valid behavior works - negative cases: invalid input is rejected or handled correctly - bulk cases: multiple records work in one transaction - no-op cases: irrelevant changes do not cause side effects - async cases: Test.startTest() and Test.stopTest() frame the async execution you need to observe SeeAllData mindset: Tests should create their own data instead of relying on whatever records happen to exist in an org. That makes tests portable, repeatable, and safer in CI or a sandbox.

Worked example

@isTest
private class AccountIndustryContactTest {
    @isTest
    static void updatesContactsWhenIndustryChanges() {
        // Arrange
        Account accountRecord = new Account(Name = 'Acme', Industry = 'Technology');
        insert accountRecord;

        Contact contactRecord = new Contact(
            LastName = 'Rivera',
            AccountId = accountRecord.Id
        );
        insert contactRecord;

        // Act
        Test.startTest();
        accountRecord.Industry = 'Healthcare';
        update accountRecord;
        Test.stopTest();

        // Assert
        Contact refreshed = [
            SELECT Description
            FROM Contact
            WHERE Id = :contactRecord.Id
        ];
        System.assertEquals('Healthcare', refreshed.Description);
    }
}

// ❌ Weak test smell:
// System.assert(true);
// It executes code but proves no business behavior.

What this test proves: 1. It creates its own Account and Contact. 2. It performs the user-visible action: changing Account.Industry. 3. It queries the Contact again and asserts the observable result. 4. Test.startTest() / Test.stopTest() gives a clean frame around the operation and is essential when the behavior includes async work. What else you would add in a production suite: - a bulk test with several Accounts and Contacts - a no-change test where Industry stays the same - a negative test if the business rule should block invalid data - a test that verifies only related Contacts are changed 💡 Test behavior, not private implementation details. A future refactor should be allowed to change method names or helper structure without breaking tests that still observe the same business result.

Common mistake

❌ Common mistake: Writing tests that chase code coverage but have weak or missing assertions. Examples: - asserting true - checking only that no exception was thrown - relying on existing org data - testing only one record for trigger code that must support collections Coverage helps deployment. Assertions help correctness.

Interview angle

🎯 Interview angle Question: “What makes a good Apex unit test?” Weak answer: “It gives enough code coverage to deploy.” Stronger answer: “It creates isolated test data, runs one meaningful behavior, and asserts the observable result. I include positive, negative, and bulk cases. I use Test.startTest() and Test.stopTest() when I need to reset limits around the action or flush asynchronous work. I treat coverage as a signal, not proof of correctness.”

Pause and apply

🧠 Key takeaway: Arrange ↓ Act ↓ Assert actual behavior Try it yourself: 1. If a trigger updates related Contacts, what record should your assertion query? 2. What bug could pass a one-record test but fail a bulk test? 3. When would Test.stopTest() matter for the behavior you are verifying? 4. Why is “75% coverage” not the same as “the code is correct”?

Official references

Reviewed 2026-09-15. Examples are illustrative; no code is executed here.

Apply it in practice

Review AI-Generated Apex, LWC, and Flow Changes

Marking a lesson as read records learning activity, not mastery. Practice evidence continues to come from the challenge system.

Practice without marking read Next lesson