Your test passes in the suite. Run it alone.

A test that can start on its own

1. Run the test alone to expose state supplied by a neighboring test.
2. Keep create-and-search together when that sequence is the requirement; otherwise arrange a controlled existing order.
3. Establish sign-in and navigation before each scenario, and arrange database fixtures separately.
4. Confirm the selected test reaches its assertion, then run the group to check for interference.

The nightly suite is green. You change the order-search screen, select its test, and run it on its own. Red. It cannot find the order.

Nothing is wrong with the search yet. Yesterday's “Create order” test quietly supplied today's starting state. Your search test has a roommate, and the roommate has the keys.

This guide fixes that specific problem: a test should establish the state it needs without relying on another test having run first. You will separate a complete user journey from reusable setup, write that setup into the right place, and check one test before trusting the group again.

A group is a folder, not a setup chain

The current TestVibe shared setup documentation is explicit: there is no feature-to-feature prerequisite picker. Selecting a group neither establishes dependency order nor gives its tests a shared browser session. A sequential run limits concurrency; it does not create those dependencies.

That distinction matters when splitting a long flow. Three files named “Sign in,” “Create order,” and “Search order” look tidy, but names are not execution contracts. The last file still needs an identity and an order of its own.

Split by the question each test answers, then give each question a complete starting state. For suite structure, see the features and groups guide. For isolation of records, see test data management. Here, the question is narrower: can this particular test reach its own assertion when selected alone?

Choose between one journey and separate behaviors

Some sequences belong together. If the requirement is “a customer creates an order and immediately finds it in search,” keep creation and search in one scenario. The sequence is the behavior under test.

If the requirement is “search finds an existing order by reference,” the creation screen is incidental. Arrange an appropriate existing order, then spend the browser test on search. Otherwise a broken creation form can hide whether search still works.

The table is an example design for an order application, not a TestVibe feature dependency graph. Choose names, permissions and data appropriate to your app. A fixture must have a documented owner and lifecycle; “it is probably still in staging” is not a setup strategy.

Put shared steps before each scenario

For scenarios in one feature, use a short Gherkin Background. It runs before each scenario, not once for the group. TestVibe documents this pattern; the Gherkin reference explains the same scope.

Here is an illustrative read-only search feature. Its account, synthetic order, labels and messages must already exist in the authorized test environment. The order is deliberately kept stable for these checks; neither scenario edits it.

Feature: Find an existing order

  Background:
    Given I open the application's sign-in page
    When I sign in with "{{var:SEARCH_USER}}" and "{{secret:SEARCH_PASSWORD}}"
    Then the account menu shows "Search test account"
    When I open "Orders"
    Then I see the search field labeled "Order reference"

  Scenario: Find the seeded reference
    When I enter "{{var:SEARCH_ORDER_REFERENCE}}" in "Order reference"
    And I click "Search"
    Then the results contain the order reference "{{var:SEARCH_ORDER_REFERENCE}}"
    And the matching order has status "Open"

  Scenario: Explain a search with no matches
    When I enter "{{var:ABSENT_ORDER_REFERENCE}}" in "Order reference"
    And I click "Search"
    Then I see "No orders found"
    And the results contain no order rows

The identity check makes a failed sign-in visible before search begins. The known reference makes the positive result specific. The no-match scenario expects a resolved empty state, rather than treating an empty page during loading as success. Review the generated assertions for those distinctions; web-first assertions explain why checking the final state matters.

Keep the background relevant to every scenario in the feature. A guest-search case needs different setup, so put it in a separate feature rather than signing in and then undoing the sign-in. Markdown instructions can carry the same starting steps and expected state in their opening section.

Browser setup and data setup are different jobs

Signing in does not create the order. Creating an order does not sign a new browser in. Write down both requirements before choosing how to prepare them.

For a read-only search check, a stable synthetic fixture can be appropriate if other tests and cleanup jobs leave it alone. If the test changes a record, give it disposable data it owns. A generated unique name prevents some naming collisions; it does not stop another test from deleting the same record.

In a code-owned Playwright suite, your team can arrange data through its own fixture or helper and provide authentication through its reviewed configuration. Playwright's browser context documentation describes isolated test contexts: browser isolation concerns cookies and storage, not a reset of your application's database. A setup helper still needs to make the expected server state explicit.

Do not describe an imaginary setup API in your instructions and hope generation finds it. Either identify an existing supported setup route, arrange the controlled fixture outside the browser with your team, or include the necessary creation steps in the scenario. The create, verify, delete guide covers the last option, including cleanup.

Check the rerun you will actually use

Try this with one existing test that currently relies on its neighbors:

1. Record its missing assumptions: active identity, starting screen, records, flags and expected values. Confirm the target environment and who owns the fixtures.
2. Replace “after the login test” or “use the previous order” with explicit starting steps and controlled data. Save the revised intent.
3. If using generated Playwright, regenerate and inspect its setup and assertions. A passing execution does not tell you whether it proved the right outcome.
4. Follow Run One Test. Choose the intended run method and confirm the environment, device profiles and selected test. Playwright runs saved code; an Assistant run follows saved instructions and uses Assistant credits. Compare like with like.
5. Inspect the completed scenario and available evidence. Confirm it reached the actual search assertion. A setup failure or a skipped scenario is not evidence that search works.
6. Run the related group again. If that now fails, investigate shared records or other interference before adding sleeps or relying on an order.

This is a diagnostic sequence, not proof against every possible interaction. Run changes in scope, concurrency or environment deliberately and investigate the evidence they produce. The results documentation distinguishes run-level failures, scenario evidence and result-loading problems.

Make the next failure smaller

Pick one test you would want to rerun during an incident. Give it a named identity, a reachable starting screen, controlled data and an observable outcome. Run it without its supposed predecessor.

When it fails, the failure should tell you which assumption or behavior broke. When it passes, you should know it reached the assertion you care about. Then the group can be useful organization again, and nobody has to remember which test was holding the keys.