From one sentence of intent to a drafted test suite

The hardest part of starting a test suite is not writing the tests. It is deciding what to cover. Staring at a working app and enumerating every flow, edge case, and empty state that deserves a test is slow, and it is the step most teams skip. TestVibe's AI exploration flips that: you give it an intent, it drives a real browser against your app, and it hands back feature specs that have already passed a verification run.

This guide walks through triggering exploration, understanding what comes back, and reviewing drafts before you accept them.

What exploration actually does

Exploration lives in the TestVibe Assistant, a project-aware chat reached from the navigation rail. Open the ✨ Suggestions menu and, under Discover, choose Explore my app and suggest tests.

From there the Assistant drives a real cloud browser against your project's target site. It navigates, interacts with the UI, and proposes tests based on what it actually finds — not a generic checklist inferred from your project name. This is optional and never automatic. Creating a project does not probe your site; exploration only runs when you ask for it, and you can ask at any time.

The key distinction from a brainstorming prompt: exploration does not return a list of ideas. Every behavior it proposes is already written as a test and has passed a real verification run before you see it. That is the honest version of "AI-generated tests" — the agent proved the test works against your live app before suggesting it, so accepting a proposal is a review step, not a leap of faith.

What comes back, and when

Proposals arrive incrementally. The Assistant does not save everything up until the session ends and dump it on you — each behavior is proposed as soon as it is verified. You will see happy-path flows, but also the states most people forget:

• a form's validation error when a required field is empty
• an empty-search or "no results found" screen
• a state behind a filter or a specific data condition

These edge states are proposed with the same priority as the happy path. That matters, because edge cases are exactly what a hand-written first suite tends to miss, and they are where real regressions hide.

Because proposals stream in as they are verified, a session that gets cut short (it runs out of time, or you interrupt it) is not wasted. TestVibe keeps everything it already verified and offers a one-click Continue exploring card so you can pick up where it left off instead of starting over.

Accepting a draft

Each proposal is a complete, ready-to-run test. Accepting one keeps that test in your project. Because the test was already generated and verified during exploration, accepting it does not kick off a fresh generation — there is no second wait. The work is done; you are deciding whether to keep it.

A proposed feature looks like any other TestVibe feature: a Gherkin .feature file describing the behavior, backed by the Playwright code that runs it. For example, an empty-cart checkout guard might read:

Feature: Cart checkout guard

  Scenario: Checkout is blocked with an empty cart
    Given I am signed in as a standard user
    And my cart is empty
    When I open the cart page
    Then I do not see a "Checkout" button
    And I see a message that my cart is empty

Accepting drafts one at a time, rather than in bulk, keeps you in control of what your suite asserts. Exploration is very good at finding behaviors; you are the one who knows which of them are worth guarding.

Review before you rely on it

AI generation does not remove the need to review tests. The agent proved the test runs and passes; it did not decide whether the behavior it captured is the behavior you want to protect. Before you lean on an accepted draft, read it against a short checklist:

Test data is the one that bites people. A test that passed once against whatever state your app happened to be in may not pass on a clean environment. If a proposal depends on a specific order existing or a specific user being present, make sure that condition is repeatable — either the test sets it up, or your environment guarantees it.

If a draft is close but not quite right, edit the Gherkin before you run it as part of a group. You own the feature file the moment you accept it.

Where exploration fits

Exploration is the fastest way to go from a fresh project to a populated suite, but it is a starting point, not the whole job. A sensible workflow:

1. Create a project pointing at a reachable environment — a staging or shared QA URL the cloud session can open.
2. Run exploration to get a first wave of verified drafts across your app's core surfaces.
3. Accept the drafts that matter, editing data and assertions where needed.
4. Fill gaps by describing specific flows the explorer did not reach — deep multi-step journeys or behaviors that need particular setup.

The explorer covers breadth quickly; you add depth where your product's risk actually lives. One caveat: exploration can only verify against what the cloud session can reach, so point it at an environment that reflects real behavior, not a stubbed placeholder.

Exploration turns the blank-suite problem into a review problem, and a review problem is one you can finish. Start with an intent, let the agent do the walking, and keep the drafts that earn their place. Get early access to try it on your own app, or read the Assistant documentation for the full reference.