> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://tester.army/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tester.army/_mcp/server.

# Preparation Test

A **Preparation Test** lets one test log in (or perform any setup), save the
resulting browser session, and have every other test in a group reuse that
session. This avoids re-running login steps in dozens of dependent tests and
keeps your suite fast.

## How it works

* Pick any enabled web test in the project and mark it as a group's
  **Preparation Test**.
* The prep test does **not** have to belong to the group it prepares. Keep a
  single login test in **All Tests** and select it from as many groups as you
  like instead of copying it into each one.
* Disabled preparation tests are ignored until re-enabled.
* Whenever the group is run (manually via **Run all**, on a schedule, or via
  webhook), the prep test runs first.
* After the prep test completes successfully, its final browser session is
  written to a one-shot Kernel profile that's scoped to that single batch.
* Web tests later in the same batch open their browser with that profile
  attached read-only, so they start already logged in.
* Non-web tests still stay in the same prep-first batch ordering, but they do
  not load the saved browser session.
* Once every test in the batch finishes, the profile is deleted automatically.

Each batch gets its own isolated session, so:

* The prep test always starts from a clean slate — no state leaks in from a
  previous run.
* Two batches can run in parallel without colliding on the same session.
* Nothing is left behind to grow over time.

If the prep test fails, the dependent tests in that batch are cancelled and
the profile is still cleaned up.

## Solo runs of dependent tests

Running a dependent test on its own (the **Run** button on a single test view,
or hitting the test's API endpoint) automatically runs the group's
preparation test first and then this test, so you always iterate against the
same post-login state the group run would produce. The prep test and its
session profile are scoped to that single run and cleaned up when the test
finishes.

When a test belongs to multiple groups that each have a preparation test, the
**Preparation** card above the step flow includes a group selector. Picking a
group switches which prep flow the next **Run** click will execute, and the
choice is saved on the test so it sticks the next time you open it. Running a
test directly from a group's row uses that group's preparation test for that
run. If you never pick a group, we prefer the first non-default group with a
preparation test configured; the default group is only used as a fallback.
Running the prep test itself on its own does not trigger an extra prep pass —
it just runs the test directly.

## Set the preparation test

Set or change the preparation test from the **Configure Trigger** panel on
the **Tests** tab: click **Configure Trigger** on the group, open the
**Preparation Test** section, search for the test that should save the
session, or choose **No preparation test** to clear it. Changes take effect
when you press **Save**.

The picker searches every enabled web test in the project, so the same login
test can be reused by every group. Removing a test from a folder no longer
clears that folder's preparation test, because the two are independent.

On a test's own page, the **Preparation** card above the step flow shows the
currently configured prep test (if any) and links out to it, so you can
inspect the setup that runs before your test without leaving the iteration
loop.

## How the group is shown

Once a prep test is set, both the **Tests** tab and the **Results** tab render
the group as three sections:

* A **Preparation step** header above the prep test row.
* The prep test itself. It is listed here even when it lives in another
  folder, because it is part of what the group runs, but it stays out of the
  group's test count and cannot be reordered or removed from this group.
* A **Tests using session** divider, followed by every consumer test.

Consumer tests show a small key icon next to their name; hovering reveals which
test owns the session being reused.