Apex Tests for Controllers and Services

Salesforce requires a minimum percentage of Apex code coverage by tests before code can be deployed to production — a genuine platform requirement, entirely separate from Jest. Jest tests (Lessons 1-3) verify a component's own client-side rendering and interaction logic; they provide zero coverage toward this Apex requirement, since they never actually execute real Apex code.

@isTest
private class AccountSearchControllerTest {
    @isTest
    static void testSearchReturnsMatchingAccounts() {
        Account testAccount = new Account(Name = 'Acme Corp');
        insert testAccount;

        Test.startTest();
        List<AccountResult> results = AccountSearchController.search('Acme');
        Test.stopTest();

        System.assertEquals(1, results.size(), 'Expected exactly one matching account');
        System.assertEquals('Acme Corp', results[0].accountName, 'Account name should match');
    }
}

@isTest marks both the class and each test method. Test.startTest()/Test.stopTest() reset governor limits (Module 7) partway through the test, letting the code under test run with a fresh set of limits, isolated from setup work done beforehand. System.assertEquals(expected, actual, message) is the core assertion pattern — a clear failure message matters just as much here as in Jest.

The test above exercises AccountSearchController.search (Module 7's project) exactly as the component's @wire call would — inserting real test data, calling the method, and asserting the shape and content of what comes back, including that the wrapper class's fields (Module 7) are populated correctly.

Neither testing layer substitutes for the other. Jest verifies the component genuinely renders and behaves correctly given some data; Apex tests verify the server-side logic genuinely returns correct, secure data — and only Apex tests satisfy the platform's actual deployment coverage requirement. A fully tested feature needs both.