Put it together: your first testing project

You have practiced the individual skills. Now use them together: plan, run, review, and explain a small test suite for the practice website.

This final project has five checks. Try writing your own version first. A complete worked example is included below so you can compare approaches and continue even if you get stuck.

Your project brief

A colleague is about to change the practice form. They want a small set of checks that will help them notice if an important behavior breaks. Write a file named final-project.bru with these cases:

1. The page opens cleanly. Check its title and confirm that no old receipt is shown.
2. A valid project succeeds. Enter Ada Lovelace as the name and My first test as the project, then submit. Check both the project heading and the default detail line.
3. A missing project is rejected. Enter Ada Lovelace as the name, leave the project empty, submit, and check the invalid field and hidden receipt.
4. Choices reach the receipt. Enter Ada Lovelace and My first test, select Form submission, turn Include screenshots on, submit, and check the detail line.
5. A new submission replaces the old receipt. Enter Ada Lovelace as the name and First project as the project, then submit. Change the project to Updated project, submit again, and confirm there is one receipt with the updated heading.

Use shared navigation when it makes the file clearer. Give every case a descriptive name. Keep the two submissions in the last case inside the same test, because they are part of one journey.

One new assertion: count the receipts

The last case needs to check that there is exactly one receipt. Use expect count "#result" 1. This counts the elements matching #result and checks that the count is exactly 1. Follow it with a text assertion for the updated heading. Together, the assertions check that there is one receipt and that it names the updated project.

Work in small passes

Write the page-opening case first and run it. Add the valid submission case next. Continue one case at a time. If a new change breaks the file, you will know which small addition to inspect.

For each assertion, ask whether it really proves the result you care about. For example, a visible receipt alone would not prove that Updated project replaced First project.

If your file is not ready yet, download the worked version into a different folder so you can compare it with your own without accidentally overwriting your work.

Download the worked final-project.bru ↓

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

before_each
  navigate "."
end

test "the page opens without an old receipt"
  expect title "Bruster browser lab"
  expect hidden "#result"
end

test "a valid project produces the correct receipt"
  fill "#name" "Ada Lovelace"
  fill "#project" "My first test"
  click "button[type=submit]"
  expect text "#result h2" "Smoke test created for My first test"
  expect text "#result p" "Ada Lovelace · Navigation check · Screenshots: off"
end

test "a missing project blocks submission"
  fill "#name" "Ada Lovelace"
  click "button[type=submit]"
  expect attached "#project:invalid"
  expect hidden "#result"
end

test "the workflow and screenshot option reach the receipt"
  fill "#name" "Ada Lovelace"
  fill "#project" "My first test"
  select "#workflow" "forms"
  check "#screenshots"
  click "button[type=submit]"
  expect text "#result p" "Ada Lovelace · Form submission · Screenshots: on"
end

test "a second submission replaces the first receipt"
  fill "#name" "Ada Lovelace"
  fill "#project" "First project"
  click "button[type=submit]"
  expect text "#result h2" "Smoke test created for First project"
  fill "#project" "Updated project"
  click "button[type=submit]"
  expect count "#result" 1
  expect text "#result h2" "Smoke test created for Updated project"
end

Run and review the project

./bruster test final-project.bru --visible --output final-results

.\bruster.exe test final-project.bru --visible --output final-results

The worked solution should report 5 passed, 0 failed. Find the run folder and open results.json. Match its test names to the five requirements above.

Then change the project name in the valid-submission case. Update its expected heading too, save, and run again. Explain to yourself why both values needed to change.

Your plain-English testing glossary

Action

Something the browser does, such as opening a page, filling a field, or clicking a button.

Assertion

A statement about what must be true, such as the receipt containing the correct project name.

Automation

Having a tool repeat instructions rather than performing every action by hand.

Base URL

The starting website address used to interpret relative addresses in a test.

DSL

A small language for a specific job. Bruster’s .bru language describes browser tests.

Element and selector

An element is one part of a page. A selector is a description used to find that part.

Expected and actual results

What should happen and what really happened. A test compares them.

Profile

A collection of browser data, including cookies and other information saved by websites. Bruster gives each test a fresh browser and profile.

Regression suite

A set of tests repeated to check that previously working behavior still works.

Timeout

A limit on how long a step may wait. A matching assertion can finish before that limit.

Viewport

The browser’s current page-viewing area. It determines the visible part of a screenshot.

Artifact

A file kept from a test run, such as a report, screenshot, or diagnostic log.

What comes next?

Choose one small task on your own website and repeat the process from lesson 18. Start with a clear plan, use stable selectors, and keep the result understandable.

You can return to the Bruster DSL guide when you need another command, or explore the longer automation tutorial for website navigation and CI. The tool comparison explains which browser engine Bruster uses on each operating system, how it controls the page, and when another testing tool may fit your next project better.