Writing Your First Automated Test

Every exercise so far has been verified by running code in Execute Anonymous and reading the debug log — useful for learning, but it has a real limitation: nothing about that check survives. If the code changes next week, nobody re-runs it. Real, production Apex needs a way to verify "does this still work?" automatically, every time — not just once, by hand, right after writing it.

@isTest
private class MathCheckTest {
    @isTest
    static void additionProducesCorrectSum() {
        Integer result = 2 + 2;
        System.assertEquals(4, result, 'Expected 2 + 2 to equal 4');
    }
}

1. @isTest — on the class, marks the whole class as test-only code — it never runs as part of normal execution, only when tests are run.
2. private class MathCheckTest { — ... Test is the standard naming convention: a class named MathCheckTest tests something related to "math check."
3. @isTest — on the method, marks an individual test; every test method is static.
4. static void additionProducesCorrectSum() { — the test method.
5. Integer result = 2 + 2; — sets up a scenario and runs the code.
6. System.assertEquals(4, result, 'Expected 2 + 2 to equal 4'); — System.assertEquals(expected, actual, message) compares what you expected against what the code actually produced, and fails the test with a clear message if they don't match.
7. } — closes the method.
8. } — closes the class.

That's the entire shape: set up a scenario, run the code, assert the actual result matches what you expected.

@isTest
private class AccountNameCheckTest {
    @isTest
    static void accountIsCreatedWithTheGivenName() {
        Account acc = new Account(Name = 'Acme Corp');
        insert acc;

        Account inserted = [SELECT Name FROM Account WHERE Id = :acc.Id];
        System.assertEquals('Acme Corp', inserted.Name, 'Expected the inserted Account to keep its given Name');
    }
}

1. @isTest — marks the class as test-only.
2. private class AccountNameCheckTest { — the naming convention, applied to this scenario.
3. @isTest — marks the test method.
4. static void accountIsCreatedWithTheGivenName() { — the test.
5. Account acc = new Account(Name = 'Acme Corp'); — sets up the scenario.
6. insert acc; — insert (Module 19) is exactly the tool you already know — the insert itself is the action, nothing more needed.
7. (blank line)
8. Account inserted = [SELECT Name FROM Account WHERE Id = :acc.Id]; — a SOQL query (Module 20), reading back what was actually saved.
9. System.assertEquals('Acme Corp', inserted.Name, 'Expected the inserted Account to keep its given Name'); — asserts the actual result matches what was expected.
10. } — closes the method.
11. } — closes the class.

This is the same shape as the math example — set up, act, assert — just applied to Salesforce data instead of arithmetic. This lesson is only teaching how to wrap tools you already know in something that verifies itself automatically.

The next module\'s project — the course\'s first real trigger-based feature — is exactly the kind of code that most needs an automated test: logic that runs automatically, on data changes, potentially affecting many records at once. From here on, "I checked it in Execute Anonymous" is a fine first step while building, but it is not where verification should stop. The full "Apex Testing" module, much later in the course, goes deep — test data factories, bulk and edge-case testing, mocking callouts, meaningful coverage. This lesson's only job is to make sure the habit — write a test, don\'t just eyeball the debug log — starts now, not dozens of modules from now.