The test explorer & taxonomy

Find your way around a suite that outgrew one page: the health strip, modules, saved views, bulk actions — and where the classification actually comes from.

Forty tests fit on a page. Four hundred do not, and the flat list that worked at forty becomes the reason nobody can answer "what covers checkout?" or "which of these has never run?".

The test explorer is the Tests page rebuilt around that question. Every filter, count and page of it is computed in SQL, so nothing on screen depends on how many tests your browser happened to download.

The grouped explorer is a rollout that is switched on per workspace. Until it is on for yours, the Tests page shows the older flat card list with a tag filter. Everything below describes the grouped one.

It is not plan-gated. Viewing needs the tests:read permission; classifying and bulk actions need taxonomy:manage, which editors and above hold.

The health strip

The first thing on the page is a bar, and it does two jobs: it is the summary and it is a filter. Three segments, in the order they need you — failed, passed, never run.

It is meaningful on a project with no runs at all, which is the whole reason it replaced a row of stat tiles. "104 never run" is the most useful sentence on a fresh project; PASS RATE 0% is a number that looks like failure and means absence.

If the project has failures, the explorer pre-applies the failed filter on first load. The list you land on is the list that needs you, and clearing the filter is one click.

Control runs — the runs a sensitivity check spends, which are required to fail — are excluded from these counts. A negative control is not a failing test.

Grouping, filtering, sorting

Modules are the grouping. A module is a business capability — Checkout, Billing, Onboarding — and a test belongs to exactly one, because a default grouping has to partition: "42 tests in Checkout" stops meaning anything once some of them are also in Billing. Cross-cutting membership is what suites and tags are for.

Modules render as a chip row above the list, each with the server's count for the whole project rather than a count of what is loaded. Tests with no module group under Unclassified, which is the point of showing it.

Control	Options
Search	substring, over name and description
Lifecycle	Draft, Active, Deprecated, Archived — defaults to Active
Type	End-to-end, API, Visual, Accessibility
Sort	Recently updated, Name

Because lifecycle defaults to Active, a test you drafted and never activated is not missing — widen the filter and it is there.

A row shows the last-run status light, the name, its module and type when set, the step count, when it last ran, and markers for quarantined and pending review. Fifty at a time, "Load more" for the rest.

Saved views sit above the list: name the current search, module, lifecycle, type and sort, and get a chip back. Tick "shared" and everyone on the project has it too.

Where the taxonomy comes from — read this before you rely on it

module, actor, type, owner and risk band are all optional, and optional here is load-bearing: an unclassified test is a valid test, and nothing defaults these on your behalf.

That leaves an honest gap, and it is worth naming rather than discovering:

Modules and actors are created for you by the AI planner, which proposes a module name per test and resolves or creates the row when you generate the batch. On a project that has never run the planner, there are no modules at all — and the chip row simply does not appear, because there is nothing to group by.
Creating a module by hand, renaming one, or classifying an existing test is an API call today. POST /api/modules, POST /api/actors and PUT /api/tests/:id/classification all exist and work; no dashboard control calls them.
Consequently actor, owner and the risk override are empty on essentially every real project. Do not read an empty actor column as "nobody acts here".
A module can carry a parent, and nothing renders the nesting. It is stored, not shown.

The planner's proposals are exactly that. A blank it could not infer stays blank and lands in Unclassified, visibly, rather than being guessed — which is the right trade, and also why the Unclassified chip is usually the biggest one.

Maintenance

A sibling tab, and the only place the explorer tells you about itself:

the unclassified ratio, amber once half the project is unclassified;
each unclassified test with which part is missing — module, actor or type;
duplicate clusters, with the reason two tests were grouped.

The other sibling tab is Suites, with the suite run history under it.

Bulk actions

Tick rows, or take the Select all N matching offer, which acts on everything the current filter matches including rows not on screen. The control says which of those two it is about to do, in words, before it does it — that is the whole point of the design.

Archive is the only bulk action in the dashboard. The server also supports bulk classify, tag, quarantine and delete, on POST /api/projects/:id/tests/bulk, capped at 500 rows per call. A truncated bulk reports how many of how many it touched and tells you to narrow the filter and repeat — never a silent partial.

The review queue

When a workspace requires human review of AI-written tests, a chip appears with the pending count, and opening it replaces the list rather than filtering it.

That is structural rather than a design preference: a pending test is a draft, the explorer defaults to Active, and the list query does not select the review state at all — there is no row in this list for a facet to switch on. The queue is a different read, and it ships the steps and the recording a reviewer needs.

Filters the API has and the page does not

Server-side, the same query accepts actorId, ownerUserId, source, tag, suiteId, ruleId, quarantined and minFlake, plus sorting by creation date. None has a control. If you want "every test an agent wrote that has never been classified", that is a query string today.