Skip to content

Writing Good Tests

Worked examples of well-written tests across common testing patterns.

View as Markdown

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.

  1. 1User navigates to the login page at /login.
  2. 2Enters the email stored in the environment variable TEST_EMAIL in the email field.
  3. 3Enters the password stored in TEST_PASSWORD in the password field.
  4. 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

  1. 1User opens the contact page at /contact.
  2. 2Fills in the "Name" field with "Jane Smith".
  3. 3Fills in the "Email" field with "[email protected]".
  4. 4Types "I have a question about pricing." in the "Message" field.
  5. 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.

Check for visible UI elements, not URLs — the agent is looking at the page, not your router.

  1. 1User opens the homepage.
  2. 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

  1. 1User opens the blog index at /blog.
  2. 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

  1. 1User signs in using the credentials in TEST_EMAIL and TEST_PASSWORD.
  2. 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)

  1. 1User opens the pricing page at /pricing.
  2. 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

  1. 1User navigates to the login page at /login.
  2. 2Enters "[email protected]" as the email.
  3. 3Enters "badpassword" as the password.
  4. 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.

On this page