Salesforce Developer: Testing

Coverage is a byproduct, not a goal

Apex tests live in @isTest classes containing test methods. Each test runs in its own transaction with a fresh set of governor limits and, by default, cannot see any existing org data. The deployment requirement is 75% coverage org-wide, not per class, and every trigger needs at least some coverage. Coverage without assertions is possible and nearly worthless - the exam wants tests that fail when behavior breaks.

Concepts to name

• Test data: create your own records. Use @testSetup to build shared data once per class, and Test.startTest() / Test.stopTest() to reset limits and force asynchronous work to finish before you assert.
• Assertions: System.assertEquals, System.assert, and the newer Assert class. Assert on observable outcomes, not merely that DML did not throw.
• Callouts: Test.setMock(HttpCalloutMock.class, mock) is mandatory; real callouts are blocked in tests.
• Permissions and sharing: System.runAs() to verify profile, permission and sharing behavior.
• Utilities: Test.getStandardPricebookId() for price book entries, Test.loadData() to load records from a static resource.

Trap

Test.startTest() resets limits, so code that passes outside it can fail inside it if it was never bulkified. Another trap: seeAllData=true masks a fragile test that depends on org data and will break in a fresh sandbox or after a refresh.

Worked example

A service class updates 200 accounts. A test that inserts one account and asserts success proves nothing about limits. Insert 200, wrap the call in startTest/stopTest, then assert both the 200 updated records and that no limit exception occurred.

Rule of thumb

Write the assertion first: "after I run this, what observable thing changes?" Then create the minimum data, run, and assert exactly that.