Assertions That Actually Tell You Something

System.assertEquals(17.00, result, 'Expected the total to be 17.00');
System.assertNotEquals(null, savedRecord.Id, 'Expected the record to have been saved with an Id');
System.assert(list.size() > 0, 'Expected the list to contain at least one item');

All three accept an optional message as their final argument — always worth including, since it's exactly what shows up in the test failure output, saving whoever's debugging a failed test from having to reverse-engineer what the assertion was even checking.

// WEAK: passes even if the method returns completely wrong data
System.assertNotEquals(null, result);

// STRONG: actually verifies the specific expected value
System.assertEquals('12 + 5 = 17.00', result);

assertNotEquals(null, result) only confirms something was returned — it would pass even if calculateAndFormat(12, 5, '+') returned 'wrong answer' or '42'. This is exactly the kind of assertion that lets a real bug slip through a "passing" test suite, satisfying the coverage requirement (Lesson 1) while verifying almost nothing.

@isTest
static void discountAppliesCorrectPercentage() {
    Decimal result = DiscountCalculator.apply(200, 10); // 10% off 200

    // WEAK — would still pass even with a subtle off-by-one bug
    System.assert(result < 200);

    // STRONG — catches the exact expected value, off-by-one bugs included
    System.assertEquals(180, result);
}

If DiscountCalculator.apply had a bug computing 182 instead of 180, the weak assertion (result < 200) would still pass — only the strong, specific assertion actually catches the discrepancy. This is the single most important habit this lesson teaches: assert the exact expected value whenever one is knowable, not just a loose approximation of correctness.