Code Map

Introduction

What is the Code Map?

The Code Map screen is Testver’s structural index of your automation codebase. When you open it, Testver scans every source file in the project, extracts each method (and step definition, page object, helper, fixture, and test), and works out how they connect: which tests reach which methods, which methods call which, and which methods nothing reaches at all. The result is presented as interlocking views — Inventory, Quality, Graph, and, for Gherkin projects, Steps — backed by a detail drawer, AI assists, and an export.

The screen has two top-level tabs:

Tab	What it maps
Methods and Steps	Your automation code — the views described above. This is where Code Map opens.
Test Data	Your test data — the spreadsheets, CSVs, JSON fixtures, and property files your tests read, and which tests read them.

Note

Test Data used to be its own screen (the “Data Map” at /data-map). It is now the Test Data tab of Code Map, since both answer the same kind of question: what does my project contain, and what uses it? The old /data-map URL redirects to /code-map?view=data.

Think of it as an X-ray of your codebase. From the outside a test suite looks like a stack of green checkmarks; the Code Map lets you see through that surface to the skeleton underneath — the load-bearing helpers every test leans on, the orphaned page objects nobody calls anymore, the over-grown methods that are hard to maintain, and the duplicate code that drifts out of sync. Nothing here changes your project; it only reveals what is already there.

Note

In one sentence: the Code Map answers “what do I actually have, what is using it, and what can I safely delete or refactor?” — without you reading a single file by hand.

Who this guide is for

• QA automation engineers who want to find dead code, trim unused page-object methods, and keep a framework lean.
• SDETs / framework owners auditing test architecture — which helpers are over-used, which files are unmaintainable, where duplication is creeping in.
• Tech leads & reviewers who need a fast, file-by-file health read before a refactor or a release.
• BDD / Cucumber teams who want to see step-definition usage, undefined steps, ambiguous matches, and duplicate definitions in one place (the Steps view).
• Anyone onboarding to an unfamiliar automation repo who wants a map before diving into individual files.

Key terms (glossary)

These terms appear throughout the screen, in column headers, drawer tags, and quality hints. Skim this table once and the rest of the guide reads easily.

Term	What it means in the Code Map
Method	A single function/method extracted from a source file — the basic unit of the Inventory. Each has a name, optional class, file, line, role, language, visibility, LOC, and complexity.
Role	How Testver classifies the method’s purpose: Page Object, Helper, Support, Step Def, Fixture, Test, or Source. Shown in the Role column and as a tag in the drawer; used by the role filter.
Page object	A method belonging to a page-object class — the UI-interaction layer (locators + actions) that tests drive through. Role label page.
Helper	A reusable utility/support method (role helper or support) called by tests or other methods rather than driving the UI directly.
Step def (step definition)	A Cucumber/Gherkin step implementation — the code bound to a Given/When/Then pattern. Role step; explored in depth in the Steps view.
Dependency / call	A directed relationship between two methods: A calls B. The drawer lists both Calls (what this method invokes) and Called by methods (its callers).
Used by tests	The number of distinct tests whose execution path reaches this method (directly or transitively) — from the test itself, its setup hooks, the fixtures it asks for, or its base test class. Shown in the Tests column and as the default sort. See how a test reaches code.
Unused	A method that nothing live reaches: no test, hook, fixture, step definition or module-level code, directly or through other methods. A method called only by other unused methods is unused too. A candidate for removal, flagged with an amber Unused badge. A private constructor of a utility class (private Config() {}) is never flagged — never being called is its purpose. Static analysis only; see the warning below.
Confirmed dead	A method that is statically unused AND was never executed at runtime according to imported coverage data. Stronger signal than “unused”. Only available when coverage is present.
Cyclomatic complexity (Cx)	A count of independent paths through a method — roughly, how many branches/decisions it contains. Higher = harder to test and maintain. Shown in the Cx column; color-coded amber at ≥ 6, red at ≥ 10.
Orphan file	A source file in which every automation method is unused — a whole-file dead-code candidate (Quality view).
Orphan locator	An element/selector definition that is referenced nowhere else in the project (Quality view). Best-effort detection — verify before removing.
Entry point	A method Testver treats as a root of the call graph (e.g. a test). Entry-point tests are filtered out of the Inventory list to keep it focused on reusable code.
Maintainability score / grade	A heuristic 0–100 score (with an A–F grade) per file, combining complexity, size, unused count, and duplication. Lower = needs attention.

Supported languages & frameworks

The Code Map is language-aware: each method carries its detected language, and the source viewer and complexity heuristics adapt accordingly. Coverage of the analysis includes:

• JavaScript / TypeScript automation (Playwright, WebdriverIO, Cypress-style frameworks, plain JS/TS test code).
• Python test code (the highlighter and comment rules switch to #-style line comments for Python/Ruby).
• Java, C# and other C-family languages with classes, visibility modifiers, and // / /* */ comments.
• BDD / Gherkin (Cucumber) — features, scenarios, tags, and step definitions; the Steps view appears only when Gherkin is detected in the project.
• Page-object, helper, support, and fixture patterns common to UI automation, classified automatically into roles.

A method is found however its signature is laid out — on one line, or with one parameter per line (submitAdminCredentials( … ) {, Black-formatted Python defs ending in ) -> None:, C# with the brace on the next line).

A test uses a method — and counts in its Used by tests — when it reaches it in any of the ways the frameworks provide, directly or through other methods:

Language	How a test reaches code
JavaScript / TypeScript	Calls in the test; beforeEach / before hooks in its file; Playwright fixtures it asks for (async ({ loginPage }) =>), including the new LoginPage(page) inside the fixture; imported helpers and constants.
Java	Calls in the test; its class’s — and every base test class’s — @BeforeMethod, @BeforeEach, @BeforeClass, @BeforeAll, @BeforeSuite and @Before… methods, constructor and field initializers (a BaseTest in another file that creates the page objects counts for every test that extends it); import static …Config.BASE_URL.
C#	The same, with [SetUp], [OneTimeSetUp], [TestInitialize], [ClassInitialize] and the test class’s constructor (xUnit).
Python	Calls in the test; pytest fixtures it asks for, including fixtures that ask for other fixtures and autouse fixtures in a conftest.py above it; setup_method in its class or a base class; imported helpers and constants.

Constructing a page object counts as using its constructor (and its parent class’s). A field that is only declared — protected SearchPage searchPage; with nothing creating it — does not count.

Note

The exact set of detectable languages depends on your Testver build’s scanner. The screen surfaces whatever the indexer reports per symbol; if a method shows an unexpected role or language, it reflects the scanner’s best classification.

How the analysis works

• Zero-config — there is nothing to set up. Open the screen and Testver indexes the project automatically; the header shows the method, unused, test, and file counts as soon as it finishes.
• Fast & local — indexing runs against your local project files. The stats row reports the elapsed time (e.g. “indexed in 420ms”), so you can see how quick it is.
• Cached, and refreshes itself — the index is cached and reused while your files stay the same. When files are added, removed or saved, the next load re-indexes automatically. Rebuild forces a full re-scan whenever you want one.
• Read-only & safe — the Code Map never modifies your code. Every action (browsing, exporting, even AI assists) only reads. The drawer states explicitly that AI suggestions change nothing in your project.
• Coverage-aware (optional) — if runtime coverage data is available, the Code Map merges it in to upgrade “unused” candidates to Confirmed dead and shows per-method run-status tags.

Note

The indexer skips folders that aren’t part of your automation source — dependencies, build output, and generated report or result folders (reports/, playwright-report/, test-results/, allure-*, htmlcov/ …) — so the inventory stays focused on code you own. Source code in packages named config or reporting (a ConfigReader, a ReportingUtil) is indexed. Counts in the stats row reflect only the scanned set.

Caution

Everything flagged as Unused, Confirmed dead, orphan, or a duplicate is a candidate, not a certainty. Static analysis cannot see reflection, dynamic dispatch, string-based invocation, or runtime wiring. Always verify before deleting.

The two tabs

Each tab has its own guide:

Tab	Guide	What it maps
Methods and Steps	Methods and Steps tab	Your automation code — Inventory, Quality, Graph, and Steps views. Code Map opens here.
Test Data	Test Data tab	The spreadsheets, CSVs, JSON fixtures, and property files your tests read.

Switch with the tab bar at the top. The active tab is kept in the URL (/code-map?view=data), so it survives a refresh and can be bookmarked.

Common Tasks (How Do I…?)

I want to…	Do this
Find dead code to delete	Inventory → toggle Unused only (or Confirmed dead with coverage). Or open Quality → Orphan files for whole-file candidates.
Hand a cleanup list to a teammate or AI	Header → Copy cleanup task — a Markdown checklist of unused methods lands on your clipboard.
See which tests use a method	Click the method in Inventory → read the Used by tests section in the drawer.
Trace what a method calls / who calls it	Open the drawer’s Calls and Called by methods sections, or switch to Graph and focus the method.
Understand an unfamiliar method	Open its drawer → AI assists → Explain (or read the Source block).
Find the most fragile / complex code	Quality → Most complex methods and File maintainability (lowest scores first).
Find duplicated logic	Quality → Duplicate & near-duplicate methods, then Suggest consolidation.
Check BDD step health	Steps → Quality toggle (undefined, ambiguous, duplicate steps, tags).
Find unused step definitions	Steps → toggle Unused only.
Export the inventory for a report	Header → Export CSV (Steps view has its own CSV export).
Refresh after editing code	Reload the view: changed files are picked up automatically. Header → Rebuild forces a full re-index.

Tips & Best Practices

• Treat every flag as a candidate. Unused/dead/orphan findings are static guesses — verify against reflection, dynamic dispatch, and runtime wiring before deleting.
• Prefer Confirmed dead over Unused when coverage is available — a method that is both statically unused and never ran at runtime is a much safer removal.
• No need to Rebuild after every edit. Saved changes are picked up on the next load. Press Rebuild only when you want a guaranteed fresh index.
• Start cleanup at the bottom of the maintainability list — the lowest-scoring files and modules give the biggest return.
• Use the Graph to sanity-check before deleting — focus a method and confirm nothing meaningful flows into it.
• Configure an AI provider in Settings to unlock Explain / Document / Safe-to-delete / Generate-test / consolidation suggestions; all of them are read-only. They use AI credits, so they need the tester role or above.
• Links open in new tabs — file and test links keep the Code Map open so you don’t lose your place.
• Combine filters (search + role + sort + unused) to drill straight to the rows you care about.

Troubleshooting & FAQ

The Steps view is missing. It only appears for Gherkin/BDD projects. If your project has no Cucumber features, the Steps button in the view toggle is hidden by design.

A method I know is used shows as Unused. Static analysis can’t see reflection, dynamic dispatch, or string-based invocation. Confirm with the Graph and your own knowledge before removing — the Code Map labels these as candidates for that reason.

There’s no Confirmed-dead chip or filter. Those appear only when runtime coverage data is available to Testver. Without coverage you still get the statically-derived Unused signal.

An AI assist returns “(no response … check that an AI provider is configured in Settings)”. No AI provider is set up. Configure one in Settings to enable Explain, Document, verdicts, test/step suggestions, and consolidation.

Counts look stale after I changed code. Saved changes are picked up the next time the view loads data — reload the view. Requests made within a couple of seconds of each other share one check, so an edit saved at that very moment may need one more reload; Rebuild always forces a fresh scan.

Export failed. An error toast describes the cause. Retry, and ensure your browser allows the download.

The graph says “graph truncated (large neighborhood)”. The focus method has too many connections to draw fully. Focus a more specific method, or read its relationships in the drawer instead.

The table says “No methods match your filters.” Your search/role/unused filters exclude everything — clear the search or reset the filters.

Are AI suggestions applied to my code? No. The drawer states it explicitly: AI suggestions are read-only and nothing in your project is changed. The same goes for browsing and exporting.