Form Testing
This guide shows you how to test web forms in DontBreak: filling fields, handling file uploads and sliders, checking validation errors, and asserting that a submission actually succeeded. We'll use a job application form as the running example — the in-app Job Application and Contact Form example tests follow the same patterns.
Filling fields: Type Text vs Fill
You have two ways to put text into an input:
| Action | What it does | When to use it |
|---|---|---|
| Type Text | Types a literal string into the field you target | One-off values: a name, a message, a phone number |
| Fill | Fills the field from a saved variable/snippet | Values you reuse across tests (a test email, an address) — update the variable once, every test follows |
| Clear Field | Empties an input or textarea | Resetting a pre-filled field before typing a new value |
If a field comes pre-populated (a profile edit form, a search box with a remembered query), add Clear Field first — typing into a non-empty field appends rather than replaces.
A job application form, step by step
Fill the text fields
Add a Type Text action per field — full name, phone, cover letter textarea. Target each field visually in the live preview. For the email field, use Fill with a saved snippet (or Fill Temp Email if the form sends a confirmation you want to assert on — see Email Testing).
Handle dropdowns and checkboxes
Native selects and checkboxes are just Click actions: click the select, click the option; click the checkbox to toggle it. Custom dropdown components work the same way — click what you see.
Set sliders
For range inputs (salary expectation, years of experience), add a Slider action, target the slider, and set the percentage value (0–100).
Upload the CV
Add an Upload File action, target the file input, and attach the file to the step. DontBreak stores it and uploads it on every run.
Submit and assert
Click the submit button, then assert success (next section).
Testing validation
A form test that only checks the happy path misses the most common form bugs. Create a second test that submits the form empty or with bad data:
Submit with missing fields
Skip the required fields and Click submit straight away.
Assert the error text appears
Add a Page Contains assertion with the expected error message, e.g. "Email is required". For inline error states (a red border, an error icon next to a field), use Element is Visible targeting the error element instead.
Assert you stayed on the form
Add a URL Check to confirm the page did not navigate away — a form that submits invalid data is a real bug.
One scenario per test
Keep "valid submission" and "validation errors" as separate tests — they have different expected outcomes, so a single run can't cover both, and each fails for one clear reason that makes results easier to read. The validation test exercises logic, not rendering, so run it on a single platform (Chrome Desktop) and reserve the full browser × device matrix for the happy path.
Asserting a successful submission
After clicking submit on the happy path, prove it worked with at least one of:
- URL Check — the form redirected to a thank-you page (e.g.
/application/success). - Page Contains — the confirmation text appeared ("Thanks, we received your application").
- Element is Visible — a success banner or confirmation panel rendered.
- Email Received — the form triggered a confirmation email to your temp inbox.
Avoid asserting nothing and trusting that "the click didn't error." A submit button can do nothing at all and the test would still pass.
Next steps
Forms rarely live alone — they're usually one stage of a longer journey. See Multi-Step Workflows for chaining pages together, and Handling Dynamic Content if your form shows async validation or loading states.