Lesson 12 of 20 · Beginner course
Test choices as well as text
A form can contain choices as well as text. You will now select a workflow, turn a checkbox on or off, and check that those choices reach the receipt.
First try both controls on the practice page. Notice that the dropdown shows human-readable labels, while the live preview shows shorter values such as forms.
Choose a dropdown option with select
select "#workflow" "forms" means “choose the option whose value is forms in the workflow dropdown.” This option is labeled Form submission on the page.
| Label you see | Value used in these tests |
|---|---|
| Navigation check | navigation |
| Form submission | forms |
| Screenshot review | screenshots |
Bruster can select by option value or text. These examples use the values so you can connect the test with the live preview. Selecting an option tests the form choice; it does not test the operating system’s native popup appearance.
Set a checkbox to a known state
check "#screenshots" makes the checkbox checked. uncheck "#screenshots" makes it unchecked.
These commands express the state you want. Clicking a checkbox would instead toggle whatever state it currently has. If it was already checked, another click would turn it off.
Checking an already checked checkbox leaves it checked. This makes check helpful when you want a clear, predictable setup rather than a guess about the current state.
Read the two complete cases
This file has a before_each block. It is shared preparation that runs before every test in this file: open the page and fill the two required fields. Lesson 14 explains this setup in more detail.
base_url "https://aliilyas.github.io/bruster/demo/"
before_each
navigate "."
fill "#name" "Ada Lovelace"
fill "#project" "Bruster"
end
test "the selected workflow and checked option reach the receipt"
select "#workflow" "forms"
check "#screenshots"
click "button[type=submit]"
expect text "#result p" "Ada Lovelace · Form submission · Screenshots: on"
end
test "the screenshot option can be turned off again"
select "#workflow" "screenshots"
check "#screenshots"
uncheck "#screenshots"
click "button[type=submit]"
expect text "#result p" "Ada Lovelace · Screenshot review · Screenshots: off"
endThe first case chooses Form submission and checks the screenshot box. The second chooses Screenshot review, checks the box, and then unchecks it. Both submit before checking the final receipt.
Notice that Screenshot review and Screenshots: off can appear together. The workflow dropdown and checkbox are independent controls. A test should not assume one changes the other unless the page is designed that way.
Run the file
./bruster test choices.bru --visibleWindows PowerShell.\bruster.exe test choices.bru --visibleThe expected summary is 2 passed, 0 failed. You should see each test name separately. The second test gets a fresh browser, so it cannot depend on the checkbox left by the first one.
Check the effect, not only the action
A successful select or check command tells you the browser could perform that action. The receipt assertion adds a different piece of evidence: the form used that choice when it built its result.
This habit applies to real websites too. After changing a delivery method, check the resulting delivery information. After changing a filter, check the displayed results. The outcome should connect to the choice you made.
Try it: make a navigation case
Copy the first test block, including its test and end lines, and paste it after the last end in the file. Give the copy a new name, change the option value to navigation, and replace check with uncheck. Update the expected detail line to “Ada Lovelace · Navigation check · Screenshots: off”.
What should the summary become?
If you added the new case to the file without removing the original two, a successful run should report three passed tests.
Before you move on
You can explain why setting a checkbox with check is clearer than blindly clicking it when the goal is “the option must be on”.