Writing assertions

An assertion is a step that checks a fact instead of performing an action. It is the difference between "the button was clicked" and "the order was placed". A test made only of actions will happily pass through a completely broken flow, because clicking a button that does nothing still counts as a successful click.

123

1. 1An Assert step. It checks rather than acts.
2. 2Assert the thing that proves the journey worked, such as the order number appearing.
3. 3The four steps before it only perform actions. On their own they cannot fail meaningfully.

What to assert

Assert the thing a human would look for to know it worked. After a sign-up, that is usually a welcome message or a redirect to the dashboard. After a checkout, an order number. After a search, at least one result row. The rule of thumb: if you would not be satisfied seeing only that the click happened, neither should the test be.

• Text is present, or absent, somewhere on the page.
• An element is visible, or has disappeared.
• The URL contains an expected fragment.
• A field holds an expected value.

Where to put them

Put one at the end of every meaningful stage, not just at the end of the test. A checkout test that only asserts the final confirmation will tell you it broke, but not where. The same test with an assertion after the basket, after the address form, and after payment tells you which stage failed the moment you open the run.

Assertions that age badly

Avoid asserting on anything that legitimately changes: a cart total that varies with promotions, a timestamp, a product count that shifts as inventory moves, or copy your marketing team rewrites monthly. Those produce failures that are real in the strict sense and useless in practice, and a test that cries wolf gets ignored. Assert the structure of success rather than its exact wording where you can.