Capstone Reference Implementation: Testing and Deployment

import { createElement } from 'lwc';
import CaseList from 'c/caseList';

describe('c-case-list', () => {
    afterEach(() => {
        while (document.body.firstChild) {
            document.body.removeChild(document.body.firstChild);
        }
    });

    it('dispatches caseselected with the row\'s accountId', () => {
        const element = createElement('c-case-list', { is: CaseList });
        element.cases = [{ id: '500xx', subject: 'Login issue', status: 'New', accountId: '001xx' }];
        document.body.appendChild(element);

        const handler = jest.fn();
        element.addEventListener('caseselected', handler);

        const datatable = element.shadowRoot.querySelector('lightning-datatable');
        datatable.dispatchEvent(new CustomEvent('rowclick', {
            detail: { row: { accountId: '001xx' } },
        }));

        expect(handler).toHaveBeenCalledTimes(1);
        expect(handler.mock.calls[0][0].detail.accountId).toBe('001xx');
    });
});

This directly follows Module 14's event-testing pattern — attaching the mock listener before triggering the interaction, then asserting on the dispatched event's detail.

@isTest
private class CommandCenterServiceTest {
    @isTest
    static void testUpdateCaseStatusRejectsBlankStatus() {
        Case testCase = new Case(Subject = 'Test', Status = 'New');
        insert testCase;

        Test.startTest();
        try {
            CommandCenterService.updateCaseStatus(testCase.Id, '');
            System.assert(false, 'Expected an AuraHandledException for a blank status');
        } catch (AuraHandledException e) {
            System.assert(true);
        }
        Test.stopTest();
    }

    @isTest
    static void testGetAccountSummaryThrowsForMissingAccount() {
        Test.startTest();
        try {
            CommandCenterService.getAccountSummary(null);
            System.assert(false, 'Expected an AuraHandledException for a missing account');
        } catch (AuraHandledException e) {
            System.assert(true);
        }
        Test.stopTest();
    }
}

Following Module 14's Test.startTest()/stopTest() pattern, both the validation failure path and the not-found path are exercised directly against the Service layer — the same class the Controller merely delegates to.

Module 2's SFDX workflow applies directly to shipping this feature: authenticate to the target org, deploy the new Apex classes and LWC bundles (sf project deploy start), then confirm the deployment passed the platform's Apex coverage requirement (Module 14) — the same requirement the tests above exist to satisfy.

Running Module 16's code review checklist against this capstone, as the closing step of the entire course:

1. Separation of concerns — ✓ UI logic stays in components; business logic lives in CommandCenterService.
2. Controller/Service/Selector layering — ✓ each layer has exactly one responsibility, with the Controller genuinely thin.
3. Consistent error handling — ✓ every failure path surfaces through AuraHandledException and ShowToastEvent, matching the pattern used throughout the course.
4. Appropriate configuration use — the capstone's requirements didn't call for admin-tunable values, so no Custom Metadata was introduced — correctly recognizing when configuration-driven design isn't needed is as much a sign of good judgment as using it when it is.

This is the same discipline applied consistently across all 20 modules — from Module 1's first "Hello Salesforce" component to this finished, tested, deployed feature.