Test Explorer

Introduction

What is the Test Explorer?

The Test Explorer is the screen at route /tests. It scans your project’s source files, finds every automated test (across many frameworks), and presents them as an organized, searchable list. For each test it shows the framework it belongs to, its most recent result, how many times it has run, its pass rate, any tags or modifiers, and gives you a one-click Run button. Click any test to drop into a full-screen Detail View with tabs for Steps, Source code, run history (Runs), live Output, mapped manual test cases, and the framework Methods it uses.

Think of it as the table of contents for your test code. Just as a book’s table of contents lists every chapter with a page number without you having to flip through the whole book, the Test Explorer lists every test with its status and location without you having to open files in an editor or remember command-line incantations.

Note

In one sentence: the Test Explorer turns the test files scattered across your codebase into a single, filterable, runnable list with full result history.

Who this guide is for

• QA engineers and testers who need to find a specific test, run it, and read its result without touching a terminal.
• Developers who want to check whether the tests for a feature are passing, view the source of a failing test, or re-run a flaky one.
• Test leads and managers who want an at-a-glance pass-rate summary and the ability to export the test inventory to CSV or Excel for reporting.
• Anyone onboarding to a project who wants to understand what is tested, in which frameworks, and where the test files live.

Key terms (glossary)

These terms appear throughout the screen and this guide. Skim them once and the rest of the manual will read smoothly.

Term	What it means in the Test Explorer
Test	A single automated test case found in your source (for example one it(…), one Cucumber scenario, or one @Test method). It is the smallest runnable unit shown in a row.
Suite	A group of tests that live in the same file. Suites are the collapsible cards in the list; their name comes from the file or the top-level describe/feature block.
Framework	The tool the test is written for: Playwright, Jest, Vitest, Cypress, Cucumber, Mocha, Pytest, JUnit, TestNG, NUnit, xUnit, MSTest, RSpec, or Robot. Shown as a coloured badge.
Run	One execution of a test (or set of tests). Each run produces a result and is recorded in the test’s history.
Status	The result of the most recent run: passed (green check), failed (red X), skipped (grey minus), or no result yet shown as an empty circle.
Pass rate	The percentage of a test’s runs that passed, computed as passed runs / total runs. At the page level it is passed tests / tested tests (tests with at least one run).
Tag	A label attached to a test in the source (for example @smoke, @regression). Shown as cyan chips and usable as a filter.
Modifier	A marker on the test declaration that changes how it runs or what it means: skip, only, todo, fixme, or slow. Shown as small coloured badges.

How it works

The Test Explorer does not run your tests in order to list them. When you open the page it scans your source files (you will briefly see Scanning test files…) and parses out every test declaration it can recognize. This is why a brand-new test appears in the list immediately after you save the file, even though it has never been executed.

Each discovered test is then matched against your run history. Testver remembers the results of every run you have performed (locally or on a cloud grid). When a test name matches a recorded result, the row is enriched with its last status, run count, pass/fail counts, and pass rate. A test with no matching history shows as No Run — it exists in your code but has never been executed through Testver.

Note

Two independent data sources feed every row: the source scan (what tests exist, their tags, modifiers, line numbers, framework) and the run history (what happened when they ran). A test can exist without history; history is never invented.

Getting Started

Opening the Test Explorer

1. Open Testver in your browser and make sure a project is loaded.
2. Navigate to the Tests screen (route /tests). It is labelled Test Explorer in the top-left of the toolbar, next to the test-tube icon.
3. Wait briefly while you see Scanning test files… — Testver is reading your source.
4. The list appears. If no tests are found you will see an empty state with guidance (see Troubleshooting).

Tip

If you change a test file while the page is open, click the circular Refresh button on the far right of the toolbar to re-scan and pull in your edits.

The two views

The screen has exactly two modes. You are always in one or the other:

View	When you see it	What it is for
List View	The default. Shown whenever no specific test is selected.	Browsing, filtering, searching, sorting, multi-selecting, bulk-running, and exporting the whole catalogue of suites and tests.
Detail View	Appears full-width the moment you click a test row.	Deep inspection of one test: its steps, source code, run history, live output, mapped manual test cases, and the framework methods it uses.

The Detail View replaces the list (it is not a side panel). A Back to Tests bar at the top returns you to the List View. The selection is reflected in the URL via ?file= and ?test= parameters, so a detail view is shareable and survives a page reload.

Screen layout

From top to bottom, the List View is built from these horizontal bands:

Region	Location	Contents
Header toolbar	Top	Test Explorer title, status filter chips (All / Passed / Failed / No Run), framework dropdown (if more than one framework), and the right-side actions: Tags, Export, Refresh.
Tag panel	Below toolbar (when opened)	The tag cloud for filtering by tag, or — when the cloud is closed but tags are active — a compact row of active tag chips.
Statistics strip	Below tags	Five stat pills: Total, Passed, Failed, No Run, and Pass Rate. Reflects the current filters.
Search + Sort + Bulk bar	Above the list	Search box, the four sort buttons, and (when tests are selected) the bulk-action controls.
Suite list	Main scrollable area	The collapsible suite cards and, when expanded, their test rows.

The List View

Status filter chips

At the top of the toolbar are four chips that filter the list by the most recent result of each test. Exactly one is active at a time; click another to switch. The active chip is highlighted in its status colour.

Chip	Icon	Shows	Active colour
All	—	Every test, regardless of status.	Brand (default)
Passed	Green check	Only tests whose last run passed.	Emerald
Failed	Red X	Only tests whose last run failed.	Red
No Run	Empty circle	Only tests that have never been run (run count is zero).	Grey

Note

Selecting Passed, Failed, or No Run automatically expands all matching suites so you can see the tests immediately, rather than having to open each card.

Framework filter

When your project contains more than one test framework, a Filter funnel icon and a dropdown appear in the toolbar. The dropdown lists All Frameworks plus one entry per detected framework (sorted alphabetically). Pick one to restrict the list to just that framework’s suites.

Note

If your project uses only a single framework, the dropdown is hidden entirely — there is nothing to choose between.

The Tags panel

If any test in the project carries tags, a Tags button appears on the right of the toolbar. It shows a count in parentheses when tag filters are active (for example Tags (2)) and turns cyan while it or any tag filter is active.

Click Tags to open the tag cloud beneath the toolbar. It is labelled Filter by tags: and lists every tag found across all tests, each with its usage count in parentheses, sorted most-used first. Clicking a tag toggles it as a filter; active tags turn cyan and show a small X. A test matches if it has any of the selected tags (OR logic). A Clear all link removes every tag filter at once.

When you close the cloud but still have tags selected, a slim active tag chips row stays visible (a tag icon followed by the selected tags). Each chip can be clicked to remove that one tag, and a Clear link removes them all.

Tip

Tags also participate in the search box — typing a tag name into search matches tests carrying that tag, even without opening the tag panel.

The statistics strip

The strip of pills summarizes the tests currently in view. Crucially, the numbers respect your active filters — when any status, framework, tag, or search filter is on, the stats recompute from only the filtered tests; with no filters they reflect the whole project.

Stat	Icon / colour	How it is computed
Total	Plain	Count of all tests in the current (filtered) view.
Passed	Green check	Tests whose last status is passed.
Failed	Red X	Tests whose last status is failed.
No Run	Grey circle	Tests with a run count of zero.
Pass Rate	Colour-graded	Passed divided by tested tests (Total minus No Run), as a percentage to one decimal. Green at 90%+, amber at 70–89%, red below 70%, and a dash - when there are no tests.

Search and sort

Just above the suite list sits a Search box (placeholder Search suites, tests, or tags…). It filters live as you type and matches against the test name, the suite name, and the test’s tags. A small X clears it. Searching auto-expands all matching suites.

Next to the search box are four sort buttons. Click one to sort by that field; click the same button again to flip between ascending and descending. The active sort button is highlighted and shows an up or down arrow (an inactive button shows a faint up-down icon). Sorting reorders both the suites and the tests within them.

Button	Sorts by
Name	Alphabetical by test/suite name (the default).
Status	By last result, ordered failed first, then passed, then skipped, then no-run.
Runs	By how many times the test has run (suites by total runs).
Rate	By pass rate. Tests/suites with no runs sort to the bottom.

Note

A fifth sort field, tags (by number of tags), exists in the engine but is not exposed as a button in the toolbar — the visible buttons are Name, Status, Runs, and Rate.

Multi-select and bulk run

Each test row has a checkbox (visible on hover, or filled when selected). Tick one or more tests to enter multi-select mode. A bulk-action bar then appears under the search row showing N selected plus these controls:

Control	What it does
Run Selected	Builds a single framework-appropriate command that targets exactly the checked tests and runs them together. Only shown when at least one test is selected. After launching, the selection is cleared.
Select All (N)	Selects every test currently passing the filters (N is that count).
Deselect All	Clears the entire selection.

Run Selected groups the chosen tests by framework, picks the largest group, and emits the right command for it — for example npx playwright test -g "...", npx jest -t "...", pytest "file::name", mvn test -Dtest="Suite#test", dotnet test --filter "...", robot --test "...", and so on. Test names are escaped where the framework treats the filter as a regex.

Caution

Run Selected builds the command for the largest single framework group among your selection. If you select tests spanning several frameworks, only the dominant framework’s tests are launched in that run.

Export (CSV / Excel)

The Export button (download icon, with a chevron) opens a small menu offering CSV and Excel, each labelled with the number of tests that will be exported. If you have tests selected, a header reads N selected and the export is limited to your selection; otherwise it exports everything currently passing the filters. Files are named testver-tests-YYYY-MM-DD with the matching extension.

The CSV export is a single flat table. The Excel export is a workbook with three sheets: a Tests sheet (the same columns as CSV), a Summary sheet (Total Tests, Passed, Failed, No Run, Pass Rate, Frameworks — all computed from just the exported tests), and a Tags sheet (each tag with its test count, present only if the exported tests carry tags).

Column (Tests sheet)	Meaning
Test Name	The test’s name.
Suite	The suite (file/describe) it belongs to.
File	The source file path.
Framework	The framework it is written for.
Status	Last result, or no run.
Run Count	Total executions recorded.
Pass Count	How many runs passed.
Fail Count	How many runs failed.
Pass Rate	Pass count / run count as a percentage, or - if never run.
Tags	All tags, separated by ; (CSV) or , (Excel).
Description	The test’s description, if any.
Modifiers	Any modifiers (skip/only/todo/fixme/slow), joined.

Suite cards

The main area is a stack of suite cards — one per file. Each card is collapsible and carries, from left to right:

Element	Description
Expand chevron	Right-pointing when collapsed, down-pointing when expanded. Click anywhere on the header to toggle.
Folder icon	An amber open-folder icon marking the suite.
Suite name	The file/suite name (truncated with a hover tooltip showing the full name).
Framework badge	The coloured badge for the suite’s framework (Playwright, Jest, Pytest, etc.).
Pass/total fraction	For example 7/8 — passed tests over total tests. Green when all pass, grey otherwise.
Mini progress bar	A tiny bar split green (passed) and red (failed) proportional to results.
Run-suite button	A small Play icon that appears on hover. Clicking it runs every test in the suite file (see Troubleshooting for how this differs from a single-row run).

Note

The card’s left edge is tinted: emerald when every test in the suite passed, red when any test failed, and transparent otherwise — a quick health cue while scrolling.

Test rows

Expand a suite to reveal its test rows. Each row is clickable (opening the Detail View) and contains, from left to right:

Element	Description
Checkbox	For multi-select. Hidden until you hover the row, or shown filled (brand-coloured) when ticked. Clicking it toggles selection without opening the detail view.
Status icon	Green check (passed), red X (failed), grey minus (skipped), or empty circle (no run).
Test name	The test’s name, truncated with a hover tooltip for the full text.
Modifier badges	Small coloured badges for any modifiers (see table below).
Tag chips	Up to three cyan tag chips; extra tags collapse into a +N indicator.
Run history dots	A small row of up to six dots approximating recent results (green = pass, red = fail). Hidden when the test has never run.
Run count	For example 5x — how many times the test has run. Shown only when there is a last status and at least one run.
Run button	A Play icon appearing on hover; clicking it opens the test’s Detail View ready to run (the detail panel handles the actual execution).

The modifier badges decode as follows:

Badge	Colour	Meaning
SKIP	Amber	The test is marked to be skipped (from the skip flag).
only	Blue	The test is focused — only it (and other only tests) would run.
todo	Purple	A placeholder test marked as not yet implemented.
fixme	Red	The test is known-broken and flagged to be fixed.
slow	Amber	The test is marked slow (longer timeout / known to be lengthy).

The Detail View

Clicking any test row opens the full-screen Detail View for that test. From top to bottom it has a back bar, a header, run controls, a tab bar, and the active tab’s content.

Back bar

The top strip holds a Back to Tests link (left arrow) that returns you to the List View, a divider, and then the suite’s name (with a file icon) for context.

The header

The header presents the test at a glance:

• A large status tile — green/red/grey background with the matching status icon.
• The test name as the heading.
• The framework badge.
• A file:line link (for example tests/login.spec.ts:42) with an external-link icon. Clicking it opens that exact location in the Project Explorer in a new browser tab.
• When the test has run: the run count (for example 12 runs) and the pass rate (colour-graded green/amber/red).
• A tags / modifiers row repeating SKIP, the modifier badges, and the full set of tag chips.
• The test’s description, shown in italics, if one exists.

Run controls

If the test has a runnable command, an action row sits below the header:

Control	Behaviour
Run Test	Launches the test. While it runs the button becomes Stop.
Stop	Cancels the in-progress run.
Command pill	Shows the command Testver will execute, tagged Auto (generated) or Custom (when you have configured a custom single-test command in settings).
Copy button	Copies the command to your clipboard (shows a green check briefly on success).
Mobile device picker	For mobile/Appium tests only: a local-and-cloud device picker (parity with the Runner). Until you pick a device — and an app, for cloud — Run Test stays disabled with a tooltip explaining what is missing.

Note

When a mobile test actually runs, a live device mirror appears in a right-hand column for the duration of the run, mirroring the Runner’s split layout.

The tabs

A tab bar exposes six views of the test. The Output tab shows a status badge (a pulsing dot while running, a green check or red X when done), and Mapped TCs shows a count badge when mappings exist.

Tab	What it shows
Steps	The human-readable steps of the test — Cucumber scenario steps (with data tables and Examples), or inferred Action/Assert/Setup steps for code-based tests.
Source	The actual test source code in a read-only editor; for Cucumber, the resolved step-definition code for each step.
Runs	The execution history of this test, with summary cards, a timeline, source filters, and drill-down into any past run.
Output	Live console output and progress of the current/most-recent run, plus post-run failure details.
Mapped TCs	Manual test cases mapped to this script (from Script Mapping), with a viewer for each case’s steps.
Methods	The framework methods (page objects, helpers, utilities) this test uses, directly or transitively, from the Code Map index.

Steps tab

For Cucumber tests this lists the scenario steps, each numbered and connected, with a colour-coded Given/When/Then/And/But keyword badge and the step text. If a step has a data table it is rendered inline. For Scenario Outlines, an Examples table follows, showing every parameter combination.

For code-based tests, Testver derives a human-readable step list from the source (each step tagged Action, Assert, Comment, or Setup). While it is parsing you see Loading test steps…. If no steps can be inferred, it suggests checking the Source tab instead.

Source tab

Shows the test’s source code in a read-only Monaco editor with the correct language highlighting and line numbers offset to match the real file. A metadata bar above the code shows the file path, the line range, the framework, and a Go to Definition button that opens the file at that line in the Project Explorer.

For Cucumber tests the Source tab is different: it shows, per scenario step, the matching step-definition code (file:line, the method name, and the source), with a N of M steps resolved counter and a per-step Go to Definition button. Steps whose definition cannot be found show a Step definition not found notice.

Runs tab

This is the test’s complete result history. When the test has runs, three summary cards appear at the top: Total Runs, Pass Rate (colour-graded), and Failures. If a last-used browser is recorded, a line notes it.

Below that, Execution History opens with a row of up to twenty coloured timeline dots (green/red/grey). Hovering a dot shows its status and timestamp; clicking a dot opens that run’s full execution detail.

Local / cloud source filters

If this test has run on more than one source, a Filter: row of toggle chips appears — Local plus any cloud grids it ran on (Sauce Labs, BrowserStack, LambdaTest). Chips only appear for sources this test actually used. The filter is multi-select; with nothing selected, all runs are shown.

History entries

Under the dots is a list of the most recent runs. Each entry shows the status icon and label, the duration, a Local or cloud-provider badge, and browser information. When a single run produced several instances (multi-browser fan-out or a Scenario Outline), the row shows an instance count plus per-browser icons. Each entry is clickable to open the full run detail.

Drilling into a run shows a Back to History header (with that run’s status and timestamp) and the full execution detail. When a run produced multiple matching instances, a selector row lets you switch between them — labelled Examples: with parameter chips for Cucumber outlines, or Runs: with browser chips otherwise. Helpful messages cover the cases where the test was renamed/removed or the run data is no longer available.

Output tab

Before any run, this tab is an empty prompt: No test output yet — Run the test to see live output here. When you start a run, the view auto-switches here.

While running, an execution header shows a spinner and Running… with an elapsed-seconds counter, a live progress bar (green/red split), the current test number, running pass/fail tallies, and the name of the test currently executing. Console output streams live below in a terminal-style pane with ANSI colours preserved (stderr lines in red).

When the run finishes, a compact summary line replaces the progress band — colour-tinted by pass rate — showing Run Complete or Run Failed, the elapsed time, total/passed/failed/skipped counts, and the pass rate. It offers View Full Results (jumps to the Results screen for this run) and a Dismiss button.

Below the summary, a Failed Tests panel expands each failure with its screenshot (click to enlarge in the viewer), the error message (with a copy button), a collapsible stack trace, a per-step pass/fail breakdown, and — for Playwright — Download Trace and Open in Trace Viewer links. If there were no failures but screenshots exist, a Screenshots thumbnail strip is shown instead.

Mapped TCs tab

Shows the manual test cases mapped to this script file (created in Script Mapping). If there are none, an empty state explains how to create mappings. Otherwise the mappings are split into Mapped to this test and Other mappings in <file>.

Each mapped case shows its title, ID, a priority badge, a type badge, a sync-status badge (Synced / Case Updated / Script Updated / Script Missing), and an automation-status badge (Automated / Manual). An eye button opens a modal with the case’s preconditions and a Test Steps table (#, Action, Expected Result, Test Data).

Methods tab

Lists the framework methods — page objects, helpers, utilities — this test uses, directly or transitively, drawn from the Code Map index. While analyzing it shows Analyzing usage…. If none are found (for example a test using only built-in framework calls, or helpers that cannot be resolved statically), it says so.

When there are methods, a count line precedes the list, and — if there are more than four — a filter box lets you narrow by method name, class, or file. Each row shows the method name, its class, a role badge, and its file:line, with three actions: open in Project Explorer, open in Code Map · Inventory, and copy the method name.

Common Tasks (How Do I…?)

Goal	How
Find a specific test	Type part of its name, suite, or tag into the Search box. Matching suites auto-expand.
See only failing tests	Click the Failed status chip.
See tests that never ran	Click the No Run status chip.
Run one test	Hover its row and click the Play icon, or click the row and press Run Test in the Detail View.
Run a whole file	Hover the suite card header and click its Play icon.
Run several specific tests at once	Tick their checkboxes, then click Run Selected.
Run everything matching a filter	Apply your filters, click Select All, then Run Selected.
Filter by one framework	Use the framework dropdown (visible only with multiple frameworks).
Filter by tag	Click Tags, then click the tags you want.
Read a test’s code	Open the test and use the Source tab.
See a test’s run history	Open the test and use the Runs tab.
See only cloud runs of a test	In the Runs tab, click the cloud-grid chip(s) in the Filter row.
Export the inventory	Click Export and choose CSV or Excel.
Jump to the file in the editor	Click the file:line link in the detail header, or Go to Definition in the Source tab.
Find which mapped manual cases cover a script	Open the test and use the Mapped TCs tab.
See what helpers a test relies on	Open the test and use the Methods tab.

Tips & Best Practices

Tip

After editing a test file, hit Refresh so the scan picks up renamed, added, or removed tests.

Tip

Combine filters: a framework + the Failed chip + a tag gives you, for example, all failing Playwright smoke tests — and the stat strip then summarizes exactly that subset.

Tip

Use Select All after filtering, then Run Selected, to re-run an entire failing subset in one go — but remember it runs the largest single-framework group only.

Tip

Export to Excel rather than CSV when you want the ready-made Summary and Tags sheets for a status report.

Tip

The left-edge colour of a suite card (green/red) lets you spot unhealthy files while scrolling, before expanding anything.

Tip

For Playwright failures, the Open in Trace Viewer link in the Output tab is the fastest path to a step-by-step replay of what went wrong.

Troubleshooting & FAQ

Why is a test showing ‘No Run’ / why is its Runs tab empty?

No Run means Testver found the test in your source but has no recorded execution of it. The test exists; it has simply never been run through Testver, so there is no history to show. Likewise the Runs tab will read No execution history yet. Run this test to see results here. The fix is simply to run it once — from the row’s Play button, the Detail View’s Run Test, or as part of a suite or bulk run. (If you ran it in some way Testver did not capture, the result will not appear.)

I see ‘No runs match the selected filter’ in the Runs tab.

The test does have history, but the Local/cloud Filter chips you have toggled exclude all of it. Clear the filter selection (deselect the active chips) to show all runs again.

What’s the difference between the suite Play, the row Play, and Run Selected?

Action	What it runs	How
Suite Play (card header)	Every test in that one file.	Builds a file-level command for the whole suite and launches it immediately.
Row Play (single test)	Just that one test.	Opens the test’s Detail View; the run is scoped to that single test via its own command (with a name/line filter). You start it from there.
Run Selected (bulk bar)	All checked tests across the list.	Groups your selection by framework, takes the largest group, and runs them together in one command.

No tests appear at all.

You will see No tests found with guidance to add test files. Testver recognizes patterns such as .spec.ts, .test.ts, .feature, test_*.py, and *Test.java among others. Ensure your project actually contains such files and click Refresh. If scanning errored, an Error loading tests state is shown with the error detail instead.

The framework dropdown is missing.

That is expected when the project uses a single framework — there is nothing to filter between, so the dropdown is hidden.

The Tags button isn’t there.

The Tags button only appears when at least one test in the project carries a tag. No tags in the source means no tag panel.

Why does the command pill say ‘Custom’ vs ‘Auto’?

Auto means Testver generated the run command for you from the framework and test name. Custom means you have configured a custom single-test command in settings, and that is what will run.

Run Test is greyed out on a mobile test.

Mobile/Appium tests require a target device. Until you select a local device (and, for cloud, an app) in the device picker, Run Test stays disabled. The button’s tooltip tells you exactly what is missing — connect a local device or enable a cloud grid in Connectors, then pick a device and app.

Related

• Runner — the execution engine.
• Results — full run artifacts.
• Script Mapping — link tests to cases.