Read a failure and find the next step

A failed test is information to investigate. Read it as a report of what did not match, rather than a judgment about how well you are learning.

We will create a harmless failure in a copy of your first test. This lets you practice the whole process while knowing exactly what changed.

1. Make a deliberately wrong expectation

Copy first-check.bru and name the copy failure-practice.bru. Open the copy in your editor. Replace only its expected title line with:

expect title "A title the demo does not have"

Keep the rest of the file unchanged. Save it. The page’s real title is still Bruster browser lab, so this expectation should not match.

2. Run the copy and read the failure

./bruster test failure-practice.bru --output practice-results

.\bruster.exe test failure-practice.bru --output practice-results

The assertion will keep checking until its deadline. The default is five seconds for the step; starting the browser and collecting evidence can add more time. Wait for the command to finish.

Find the FAIL line, the filename and line number, and the text of the failed assertion. The summary should report 0 passed, 1 failed. You have successfully created the intended practice failure.

Notice that the test can fail even though the page itself is fine. Here, the expected result is intentionally wrong. Investigation means comparing the requirement, the test, and the actual page.

3. Use the evidence to answer a small question

Open the printed artifact folder. Look at the failure screenshot and the snapshot if they were captured. Is the correct practice page open? If so, you can focus on the title assertion instead of assuming the browser never started.

A line number refers to a line in your saved file. Your editor may show line numbers, or you can count from the top. Blank lines count too. This location tells you where to start, not necessarily the full cause.

4. Fix the expectation and run again

Change the expected title back to Bruster browser lab, save, and rerun the same file. It should now pass. Keep the two run folders long enough to compare a failing result with a successful one.

If you are keeping a permanent suite, remove the deliberately incorrect copy from your list of files to run, or leave it corrected. An intentional teaching failure should not surprise a colleague later.

A practical order for other failures

1. Check the command and file. Are you in the correct folder? Did you save the file? Is its extension really .bru?
2. Check the page. Is the intended address reachable? Does the screenshot show that page or an error page?
3. Check the selector. Does it still identify the intended field, button, or message?
4. Check the expectation. Did the agreed behavior change, or is the application showing an incorrect result?
5. Check timing last. Was the result genuinely late? A longer deadline will not correct a wrong address or typo.

A syntax error, such as an unfinished quote, is different from a failed assertion. Bruster validates files before opening a browser. If the file cannot be understood, you may get an input error without a normal run report. Fix the quoted line or missing end first.