Writing Good Tests
Worked examples of well-written tests across common testing patterns.
These examples illustrate the patterns that produce reliable, consistent runs.
Login test
Name the button you're clicking. "Clicks Sign in" is better than "logs in." For credentials, use environments instead of hardcoding values directly in the test — this keeps secrets out of your test text and makes it easy to run the same test against multiple environments.
- 1User navigates to the login page at
/login. - 2Enters the email stored in the environment variable
TEST_EMAILin the email field. - 3Enters the password stored in
TEST_PASSWORDin the password field. - 4Clicks the
"Sign in"button.
Expected outcome
The user lands on the dashboard page.
The heading "Welcome back" is visible in the top-left.
Form submission
- 1User opens the contact page at
/contact. - 2Fills in the
"Name"field with"Jane Smith". - 3Fills in the
"Email"field with"[email protected]". - 4Types
"I have a question about pricing."in the"Message"field. - 5Clicks the
"Send message"button.
Expected outcome
A success banner appears with the text "Thanks for reaching out! We'll be in touch soon."
The form fields are cleared.
Navigation check
Check for visible UI elements, not URLs — the agent is looking at the page, not your router.
- 1User opens the homepage.
- 2Clicks
"Docs"in the top navigation bar.
Expected outcome
The documentation page loads.
The heading "Getting started" is visible on the page.
The URL contains "/docs".
Content verification
- 1User opens the blog index at
/blog. - 2Clicks on the first article in the list.
Expected outcome
An article page opens. A heading is visible at the top. The article body text is present (at least a few paragraphs). The author name and publish date are displayed.
Authenticated state check
- 1User signs in using the credentials in
TEST_EMAILandTEST_PASSWORD. - 2Then navigates to
/account/settings.
Expected outcome
The account settings page is visible. The user's email address is displayed in the profile section. There is no redirect to the login page.
Use an environment variable set to store test credentials. This avoids hardcoding emails and passwords in your test text, and lets you run the same test against staging and production by switching environments.
Checkout test (partial)
- 1User opens the pricing page at
/pricing. - 2Clicks
"Get started"on the Pro plan card.
Expected outcome
The checkout page opens.
The plan name "Pro" and the monthly price are visible.
The "Complete purchase" button is present.
Error state verification
- 1User navigates to the login page at
/login. - 2Enters
"[email protected]"as the email. - 3Enters
"badpassword"as the password. - 4Clicks
"Sign in".
Expected outcome
An error message is shown on the page.
The text contains "Invalid credentials" or similar.
The user remains on the login page.