For the complete documentation index, see llms.txt. This page is also available as Markdown.

App Code

See which parts of your app your tests cover — files, areas, and gaps.

The App Code section — a top-level entry in the navigation rail — maps your connected source repository's files and app areas against which UI tests exercise them, so the parts of your app that nothing tests surface first.

App Code was previously labeled Codebase. Old links and bookmarks to /codebase still work.

Browse The Code

App Code reads your source repository like a GitHub code tab. Drill into folders with the breadcrumb, or jump straight to a file from the file-tree sidebar. Folders are listed A–Z by default; flip the Gaps first toggle to surface untested code at the top. Turn on Only gaps to hide everything except untested files, and use the search box to filter files across the whole tree.

Per-File Coverage

Expand any file to see its Tested by panel — the features that map to it, each with its last-run pass or fail status and an Open link. Mapping comes from two sources: the AI's automatic file-to-area matching, and an explicit @covers: tag on a Gherkin scenario (for example @covers:Services/CheckoutService) that links that scenario straight to a source file — add a path qualifier when a bare class name matches more than one file in your repo, otherwise the tag is left unmapped rather than guessed. If a mapping is wrong, correct it inline: remove a stale link or map a test yourself. Your corrections are sticky and survive re-scans.

Metrics And Trend

Each file and folder reports an executed-vs-tested rollup, and the hero shows an executed-lines trend as a sparkline so you can see coverage moving over time. Coverage runs collect real executed-line data for .NET (dotnet test) and Node.js (node --test / equivalent) projects; other stacks still get the structural files/areas/gaps mapping without an executed-lines number.

Branches And New Code

Pick the branch to inspect. On a feature branch, App Code highlights files that are new in that branch and flags the new ones that nothing tests yet — so you catch missing coverage before you merge.

How Areas Are Derived

An AI scan reads your source to detect the stack and infer route-grounded app areas (for example "Checkout" or "Login"), grounding them against URLs your app actually serves rather than guessing. Features are auto-mapped to those areas, and you can re-map by hand.

Before You Start

App Code needs a connected source repository. Connect one under Settings → App Repository, then run a scan to populate files, areas, and coverage. Coverage-collection runs execute in TestVibe's cloud sandboxes, the same fleet that runs your Playwright tests.

Last updated

Was this helpful?