How to isolate tests in a test set with precondition and recovery hooks

By default a test set runs sequentially: every test reuses the same browser context, sharing cookies, local storage, and any state the previous test left behind. That’s fine when the tests are designed as one user journey (“log in, then create a project, then delete it”).

When the tests are unrelated — five smoke tests for five different features — sharing state usually hurts. A failing test can leak state into the next, or a stale session can mask a real auth bug.

Independent mode flips this: each test gets a fresh browser context and, optionally, a setup test that runs before it (a “precondition”) plus a teardown test that runs after (a “recovery”). The pattern mirrors BeforeEach / AfterEach from xUnit-style frameworks.

When to use independent mode

• Tests cover unrelated features — your smoke set has tests for Login, Search, Cart, Checkout, Settings. They shouldn’t share state.
• Tests need identical starting conditions — every test must run with a freshly logged-in user, or against a freshly seeded database.
• A previous test’s failure must not block the rest of the set.

If the tests are a single user journey (log in → do thing → log out), keep sequential mode. Independent costs you a fresh browser context per test, which adds wall time.

How to enable it

1. Open the test set’s settings

   On the Runner page, find the test set in the picker. Click the … menu next to its name and choose Settings….

2. Switch the execution mode

   Pick Independent instead of Sequential. The dialog grows two new fields and a checkbox.

3. Pick a precondition test (optional)

   Choose a test from the same project that should run before each test in the set. A typical pick is a Login test — every test starts with a fresh logged-in session.

   Leave it as None if your tests don’t need shared setup.

4. Pick a recovery test (optional)

   Choose a test that should run after each test, regardless of whether the main test passed or failed. Common picks are Logout, or a test that deletes any data created during the run.

   Recovery runs even when the main test fails — that’s the point. The next iteration starts from a known-clean state instead of inheriting the dirty state the failure left behind.

5. Save

   The next time you run this set, Marriska will:

   • Run the precondition test (if set)
   • Run the main test
   • Run the recovery test (if set)
   • Repeat for the next test in the set

What you’ll see in the report

Each test’s step list includes the steps from the precondition and recovery (when configured) tagged so the UI can group them under Setup and Teardown sections. The main test’s pass/fail status is unaffected by hook failures — a recovery that fails is logged but doesn’t fail the iteration.

The parallel checkbox

The settings dialog also has a Run iterations in parallel option for parameterized tests in independent mode.

Persisted, not yet active

The flag is saved on the test set so the schema is stable, but the runner doesn’t yet fan out iterations concurrently. We’ll wire that on once we see real demand for it. For now, parameterized iterations always run sequentially even in independent mode.

When it does activate, parallel iterations will be capped by your org’s plan limit — see parallel executions on the plan tiers page.

Retry failed tests

Underneath the parallel checkbox is a Retry failed tests counter with + / − buttons. Set it from No retries (default, capped at 5 retries max).

When set, the runner watches each test’s outcome. If the main test fails AND retries remain, it:

1. Runs the recovery hook (always, even on failure — see above).
2. Runs the precondition hook again (fresh state).
3. Re-runs the main test.
4. Decrements the retry budget. Repeats until the test passes or the budget is exhausted.

The final status reported on the run is whichever attempt the test ended on — pass on attempt 3 of 3 still counts as pass.

Retries consume your quota

Every retry is a real test execution. It runs Playwright, hits AI if your test triggers it, and counts against your monthly cloud_executions quota the same as the original attempt. A test with retries=3 that always fails consumes 4 executions per iteration. Pick the cap deliberately — masking real failures with retries burns quota and hides bugs.

The retry counter is only available in independent mode. In sequential mode, re-running a test from the previous test’s mid-state isn’t a clean retry — it’s “try the broken state again, hoping” — so we don’t expose the control.

Related

• Plan tier limits — parallel-execution caps per tier
• How to schedule tests to run automatically — combine independent mode with a schedule for hands-off regression
• How to skip a test — independent mode is what makes skip safe (sequential’s cascade behaviour is the main reason to switch)