Let the browser fill in a form

Your next test will do something useful: enter a name and project, press the submit button, and check the receipt. This is the manual plan from lesson 4 written as browser instructions.

Download form-submit.bru ↓ Save it beside the Bruster program in your practice folder.

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

test "Ada can create a smoke test"
  navigate "."
  fill "#name" "Ada Lovelace"
  fill "#project" "Bruster"
  click "button[type=submit]"
  expect text "#result h2" "Smoke test created for Bruster"
end

Read the steps in order

The test first opens the demo. It then fills Your name with Ada Lovelace and Project with Bruster. The next line clicks the submit button. Finally, it checks the heading inside the receipt.

The browser follows the lines in order within this test. The submission therefore happens after both fields have been filled. If the name field could not be found, the test would stop at that problem instead of continuing blindly.

What does fill do?

fill has two pieces of text after it. The first is the selector for the field. The second is the value to put into that field.

In fill "#project" "Bruster", the selector is #project and the value is Bruster. The command replaces the field’s existing contents. This helps keep the test predictable even if that field previously contained something.

Bruster also has a type command for typing additional text. Start with fill when your goal is to set the whole value. It is easier to understand a test that says exactly what each field should contain.

Why check the receipt afterward?

The final check, just before end, begins with expect, so it is an assertion. It asks for the text inside #result h2 to match Smoke test created for Bruster.

This check connects the input to the outcome. If the button did nothing, the expected heading would not appear. If the receipt used the wrong project name, the text would not match.

Notice that we left Workflow and Include screenshots alone. The page’s defaults are enough for this first submission test. Testing the optional choices separately will make those cases easier to explain.

Run the new file

./bruster test form-submit.bru --visible

.\bruster.exe test form-submit.bru --visible

Look for the test name Ada can create a smoke test and a summary of one passed test. Your test now fills in a form, submits it, and checks the result.

If a test fails, compare its saved file with the example. Check the quotes, the exact selector names, and the expected receipt. Save the file before running it again.

Change the example deliberately

Suppose you want the project to be Garden club. You need to change two things: the value in the Project fill command, and the expected receipt heading. Those two values describe the same scenario.

Changing the input alone should cause the old assertion to fail. That is useful feedback: the assertion is actually checking the outcome, rather than passing regardless of what you entered.

You can also change the human-readable test name to describe your scenario. The name does not need to match a field value, but it should still make sense when you read the result list.