Write a test case

A test case is a name, a list of steps and an Expected Outcome, written in plain English. Optional settings say where it starts, whether it logs in first and how long it may run. Testmode turns the steps into browser operations the first time the test runs, and replays them on every later run.

1. Open Test cases and click New test case, or press C on that page. The Create test case dialog opens.

2. Type a name at the top that says what the test checks, such as Contact form sends a support message.

3. Under Test Steps, click Add step for each step and type it.

4. Under Expected Outcome, describe what the page shows when the test has passed.

5. Set the optional fields below if you need them.

6. Click Create.

Create stays disabled until the test case has a name, at least one step and an Expected Outcome. Writing test cases needs the Editor role or above; Viewers can open a test case to read it.

What the test checks, in a few words. It names the test everywhere: lists, run pages, report emails and CI logs, so a failing test’s name should already say what broke.

The actions, in order, one goal per step. Drag a step by its handle, or use its arrows, to reorder it, and use its trash icon to delete it. Each step can contain variables: click Insert variable in the step to add one. See Write effective steps.

The editor points out two things as you write:

• A step that may be too vague to run reliably, such as “make a test run”, with an example of what to say instead: what to do and where.
• A step with login details in it, such as a username and password typed into a form. Move to a saved login turns them into a credential, which keeps the password out of the test and signs in before step 1.

When you save, unchanged steps keep the browser operations Testmode worked out for them; only new and reworded steps are worked out again on the next run.

What must be true on the page after the last step. Testmode checks it by reading the page, so describe something visible: a heading, a message, items in a list. It can contain variables too.

Labels such as smoke, checkout or regression, for filtering the list and for starting runs from CI by tag. Type a tag and press Enter or click Add. Tags are saved in lower case.

A stored login. With one chosen, Testmode signs in before step 1, so the test starts logged in and never needs login steps. None (no login) runs signed out. See Credentials and automatic login.

The page to open first, relative to the environment’s URL, such as /contact or /#/orders. Empty means the environment’s URL itself. It can contain a variable. Write a path, never a full URL, so the same test runs on every environment.

How long the test may run before it is stopped and fails, from 1 to 54 minutes. Leave it empty to use the project’s default, which is 15 minutes unless changed under Settings > General.

When off, the test case is left out of every run: all test cases, plans, schedules and tags, and it can’t be run on its own. Its tests still waiting in the queue are skipped and not charged; one already running finishes. Switch it off for a test that is broken for a known reason, instead of deleting it.

On when the test submits, buys, deletes or sends something real. Such a test is left out of runs on a production environment unless that environment allows tests that change data. Self-driving marks the tests it finds that do. See Pause testing and protect data.

1. Fill "First name" with "Maren", "Last name" with "Veld" and "Email address" with "maren.veld@example.com".
2. In "Subject", choose {{Contact Subject}}.
3. Type {{Support Message}} into "Message" and click "Send".

Expected Outcome: The page shows "Thanks for your message! We will contact you shortly."

• Start path /contact opens the form directly, so no step navigates there.
• It sends a real message, so it is marked Changes data and stays off production.
• Every field and button is quoted as the page shows it.
• The subject and message come from the variables {{Contact Subject}} and {{Support Message}}, so several tests share them.
• The outcome is a message the page shows.

Click a test case to open it. The ⋯ menu on its row offers:

When two people edit the same test case, the second save is refused with “Someone else changed this test case since you opened it, so your changes were not saved.” Copy what you want to keep, click Reload to see their version, and make your change again. A save never silently overwrites someone else’s, Self-driving’s included.

When Self-driving changed a test case, its editor lists Self-driving’s changes at the bottom, each with Undo, which puts back what was there before. On Test cases, the Last change column says whether you or Self-driving changed it last. See See what Self-driving did.

• The assistant writes test cases from a description and saves them after you confirm. See Ask the assistant.
• Self-driving writes and fixes test cases on its own, by your project’s goal. See Turn on Self-driving.
• An exploration visits your app and suggests test cases to add. See Start an exploration.