The suite cannot assert everything, so the choice has to be explainable. The rule is to assert the properties that break most often and that users depend on most, and to leave the rest to the audit list. The reason is written next to the assertion so the next person can disagree with it.
About 1 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
Decide and record for three gaps
Take the top gap
Before you run it, say out loud what it will print. Then open the answer.
Estimate the break rate
Before you run it, say out loud what it will print. Then open the answer.
Write the assertion with its reason
Before you run it, say out loud what it will print. Then open the answer.
Record the deferrals
Before you run it, say out loud what it will print. Then open the answer.
The asserted list and the deferred list. The deferred list is not abandoned work, it is work someone agreed to do later, and it has to be visible.
When the feature it asserts on is gone. A green assertion on a removed feature is a lie about the suite, so removal is part of the change.
The markup that changed since the last release is the likely breakage. Assert what changed first, then what has been stable.
One assertion on the page most users load is worth more than three on a page few reach. Weight by reach, not by how interesting the check is.
A comment naming why the assertion exists. Without it, the suite grows by duplication and nobody can remove a stale check.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.