Wait for a result without guessing

A website may need a moment to show its result. A reliable test waits for the thing it needs, rather than guessing how many seconds the page will take.

Our demo updates its receipt immediately. A real website might ask a server for information first. That server could answer quickly one day and more slowly the next. The test still needs a clear way to decide when to check the result.

Assertions already know how to wait

When Bruster reaches an assertion, it checks the current page. If the expected result is not there yet, it repeats the observation until the result matches or the step’s deadline is reached.

For example, expect text "#result h2" "Smoke test created for Bruster" can wait for that heading and text to appear. It does not need you to place a fixed pause before the assertion.

If the result is already correct, the assertion can finish immediately. A five-second deadline is a maximum wait for that step, not a mandatory five-second pause.

Understand timeouts

A timeout is a limit on how long a step may wait. Bruster’s default per-step deadline is 5,000 milliseconds. There are 1,000 milliseconds in a second, so that means five seconds.

You can write the deadline near the top of a test file, outside the test blocks:

base_url "https://aliilyas.github.io/bruster/demo/"
timeout 5000

This setting is applied to each step. It is not a promise that the whole test file will finish in five seconds. Running a file can involve many steps, plus time to start the browser and save reports.

Why a fixed pause is a weak substitute

Imagine always waiting three seconds before checking a receipt. If the receipt appears after half a second, you wasted the rest of the wait. If it appears after four seconds, the pause was not long enough.

Waiting for the actual receipt is more useful. It links the waiting behavior to the requirement: “the correct receipt should appear.” This also makes the test easier for another person to understand.

You do not need to add a sleep command to the course examples. Use the built-in assertions to describe the state you want to observe.

Actions and assertions do different jobs

Before a click, Bruster waits for the target to be ready—for example, visible and enabled. It then performs the click once. An assertion, in contrast, repeats its observation until the result matches or the timeout is reached. Bruster does not repeatedly click Submit until the test passes.

This distinction matters. Repeating a click could submit something twice. Repeating a read of the receipt is normally the intended way to wait for the result.

If you later use the advanced expect js command, make sure its JavaScript only reads the page rather than changing it, for the same reason. You will not need that command for the core exercises in this course.

Change a deadline only for a reason

You can override a file’s deadline for one run:

./bruster test result-checks.bru --timeout 10000

.\bruster.exe test result-checks.bru --timeout 10000

This allows ten seconds per step. It may help when a real application legitimately needs more time. It will not fix a misspelled selector, an incorrect expected message, or a server that never responds.

When a timeout happens, first check the actual page and the failing line. Ask whether the expected result was merely late, or whether it could never match. Those are different problems.