Features

The report itself

The output is one static HTML file. There is no server to run, no asset folder that has to travel with it, and no build step: you can mail it, publish it as a CI artifact, or open it off a stick. Everything below lives inside that one file.

$ pip3 install pytest-html-reporter
$ pytest tests/

• Self-containedThe default is ., so a plain run writes ./pytest_html_report.html. Pass --html-report to move it, with strftime placeholders if you want a folder or a filename per run.
• Named and badged--title sets the heading, capped at 20 characters with the cut tail faded out and the full title kept as the heading's tooltip. --environment puts a badge beside it, capped at 10 characters the same way.
• Predictable in sizeEach build kept in Archives costs roughly 5KB of the page. Retention is what keeps a long-running job's report quick to open.
• Mirrored in pytest.iniEvery flag but --title has an ini key, so a setting that belongs to the job rather than to one command can be written down once. See Configuration.

Light and dark themes

A switch at the foot of the side nav. It is remembered per reader, and follows the operating system until somebody touches it. There is no flag and no ini key for it — the theme belongs to whoever opens the report, not to the run that produced it.

It opens itself on a local run

When the run finishes, the report opens in your browser. Nothing has to be added to get this. It only happens on a run somebody is sat in front of, and a build agent fails every one of the three checks: the output has to be a terminal, no CI variable may be set (CI, GITHUB_ACTIONS, JENKINS_URL and the rest of the usual set), and on anything that is not macOS or Windows there has to be a DISPLAY or WAYLAND_DISPLAY to open into.

$ pytest tests/ --report-open=none      # never open it
$ pytest tests/ --report-open=always    # open it whatever the run looks like
$ pytest tests/ --report-open=auto      # the default, as described above

[pytest]
report_open = none

The browser is asked for a tab rather than a window, so a suite run over and over does not bury the desktop. A machine with no browser on it is not an error: the report is written either way, and a run that could not open it still passes or fails on its tests alone.

Links of your own in the side nav

--report-link adds an entry to the report's side nav pointing at any page you like — the annotated coverage source, a CI job, a Grafana board, an internal wiki page. Repeat it as often as you need. Relative paths are resolved from wherever the report is written, so linking a folder that ships beside it works, and links open in a new tab.

$ pytest tests/ --report-link "Coverage=htmlcov/index.html" \
                --report-link "CI job=https://ci.example.com/job/42"

Reading a run

The Dashboard answers how did this run go? — the counts, the shape of the failures, and whether the suite is moving in the right direction.

The Test Metrics table

The table is a DataTable: search, sort, and export buttons for copy, CSV, Excel, print and column visibility. It already carries ten columns, which is why markers ended up as badges on the Test Steps tab rather than as an eleventh.

Environment and build details

--environment names what was under test and shows it as a badge beside the report title. --build-info takes any key=value you like and adds it to the Environment panel; repeat it as often as you want. Unlike most of the flags, --build-info entries are added to the ones set in the ini file rather than replacing them.

$ pytest tests/ --environment=prod --build-info branch=main --build-info sha=$GITHUB_SHA

The same panel states what the run kept of the output and from which log level — for example all tests: stdout, stderr and logging, logging from WARNING — so there is always somewhere to check which mode you are in.

A run built with a named profile gets one more row, Profile, saying which one — so the panel answers "where did the logs go" as well as "where did this run happen". New in 0.4.3.

One row is opt-in: --report-packages adds a Packages row listing every installed distribution and its version, the way pip freeze reads. It is off by default because it is a few hundred entries nobody reads until the day the report is the only surviving record of what was installed — and it publishes a full dependency inventory into a file that gets passed around.

The failure delta

Once there is a build to compare against, the Highlights card gains a second entry saying which way the suite is moving: ▲ +3 failures over SINCE LAST BUILD, red when there are more failures than last time and green with a ▼ when there are fewer. Nothing to configure — it appears as soon as a second build has been archived.

The absolute count tells you how bad this build is; the delta tells you whether it is getting better, which is the one you act on. Hovering it gives the two counts behind it — 12 failures this build, 9 in the build before it — because +3 reads very differently against 3 than against 300. No change is written ±0 failures rather than 0 failures, which beside SINCE LAST BUILD would say the opposite of what it means, and a first build leaves the entry out entirely rather than comparing against a build that does not exist.

Reading a failure

A status column tells you a test failed. Everything in this section exists to shorten the distance between seeing that and doing something about it.

Copy the error, the rerun command, or the link

Four buttons sit beside a failure message, folded behind a ... until pressed:

1. Expand the error in place.
2. Copy the full error — it opens in the same overlay the Logs column uses, which gives the dialog a Copy button and a readable body.
3. Copy the rerun command — pytest path/to/test.py::test_name, built from the test's node id rather than by joining the suite and test names in the row, because a test inside a class is listed under its own name where pytest wants the class in front of it.
4. Copy the link to that row (see Deep links below).

$ pytest "tests/test_cart.py::TestCart::test_add[sku-A-12]"

A node id a shell would not read as one word is quoted, since a parametrised test's brackets are a glob pattern to zsh.

A click also puts a word in the middle of the page — Error copied, Command copied, Link copied — faded in and gone 2.2 seconds later, because 22 pixels of button at the end of a long row is not legible from wherever the pointer is, and because it says which of the three landed. It takes no clicks, so the row underneath stays live while it is up, and it shows four lines of what went onto the clipboard with anything past that faded out. Only one row is open at a time; a click anywhere else, or Escape, shuts it.

Status filter chips

The PASS / FAIL / SKIP / XPASS / XFAIL / ERROR count pills over the Test Metrics table are clickable, and drive a column search on the table under them. One click gets you "show me only the failures", which is the most common thing anybody does with a report like this.

From 0.4.3 the seven figures under the Dashboard's ring are the other end of the same filter. Each is a button that opens Test Metrics with the table already filtered to what it counted — Rerun to every test that ran more than once, since rerun is a count rather than an outcome — and a counter standing at zero is disabled rather than offering rows that are not there. The filter is in the address as #test-metrics?status=FAIL, so "the failures in last night's build" is a link somebody can be sent, and a Clear filter control stands beside the chips for the reader who arrived on one.

Truncation that says so

A cut error message ends by fading its last eight characters out rather than in an ellipsis — the same answer the report title gives to the same question. The ellipsis is still in the cell, hidden: the CSV, Excel and print exports are built from cell text, they cannot carry a gradient, and a message cut short with nothing to say so is a trap in a file read a week later.

Deep links to a single row

Every test row has an address of its own, copied from a button beside the failure, opening the report on that row whatever page of the table it has ended up on. Three decisions make the link worth sending:

• The anchor is built from the node id, not the row's positionA positional anchor still resolves — it opens whichever test has since taken that place, with nothing on the page to say it is not the one that was sent. Built from the node id, the link survives three tests being added in front of it, and a link into a CI job's latest report keeps pointing at the same test build after build.
• Readable, not a bare hashThe node id flattened to letters, digits and dashes and cut back to a whole word, with six hex digits of the whole node id after it. The slug says which test a link opens while it is still sitting in the chat window; the digits keep test_one[a-b] and test_one[a_b] apart when the slug cuts to the same string.
• It survives a re-sort, a search and a pageOnly the current page of the table is in the document, so a row on page four is not there to be found at all. Its position in the filtered, sorted set is what its page is computed from, and every filter hiding it — the search box, the column searches and the status chips — is cleared before the table is paged to it and the row is flashed.

A node id that appears twice — pytest-repeat, or a rerun collected rather than merged — has its repeats numbered, so the two rows keep separate addresses.

Analytics: how a test behaves, not how a run went

One run cannot tell you whether a failure is new, whether a test has been flipping for a fortnight, or whether the suite is quietly getting slower. The Analytics tab reads every build you have kept and lines them up per test. Nothing to install, nothing to configure, and nothing extra is collected: the archives already hold a status per test per build.

Under the figures, four cards name what changed since the previous build — newly failing, newly fixed, new tests and no longer run — each opening its full list in a searchable dialog. Then a sortable row per test: its verdict, its recent outcomes as a strip of one block per build, its pass rate, how many times it has flipped, its retries, how long its current streak has run and its duration. It opens worst-behaved first, so the list to work through is already the list on screen.

Analytics in full — every figure, every panel, and what the tab shows on a first run.

Test steps, Gherkin and markers

A status column tells you a test failed. Steps tell you where, and how long it had been running when it got there. Name the pieces a test is made of and they are timed, nested, and shown on a Test Steps tab of its own, with the suite drilling down to the test and the test to what it did.

from pytest_html_reporter import step

def test_checkout():
    with step("Add to cart", sku="A-12"):
        cart.add("A-12")

    with step("Charge the card"):
        assert gateway.charge(cart).ok

The same function works as a decorator, which is how the methods of a page object or an API client — already the steps of every test that calls them — get named once for all of those tests. The arguments of the call fill in the {placeholders} of the title.

@step("Log in as {user}")
def login(user):
    page.fill("#user", user)
    page.click("#submit")

login("amy")        # the tab shows: Log in as amy, with user=amy kept beside it

• The tab is never emptyEvery test has a set up, a body and a tear down, each timed, and every test carries its markers, its parameters, the fixtures it named and its docstring — so a suite that has never heard of step() still gets a tree saying where its time went. Naming steps makes that tree deeper; it does not bring it into existence.
• Steps nest by being called from inside one anotherNothing is passed between them, and a step opened in a fixture is filed under Set up or Tear down rather than swallowing the test that used it.
• A step that raises is recorded as failed, with the message, and the exception carries on outThe message is kept on the step that actually raised; the steps it was raised inside are marked failed without repeating it, so one failure is printed once rather than once per level.
• An async test names steps the same wayNew in 0.4.1. async with step("…"), and @step on an async def, with nothing to install and no setting to turn on — pytest-asyncio, anyio and trio are all driven the same way. Work run concurrently comes back as the siblings it was rather than nested inside whichever leg happened to be open, and each leg keeps its own children and its own attachments.
• Anything attached lands on the open stepattach_api, attach_json, attach_text and attach_file need no extra argument to say which step they belong to, and the step shows a paperclip. A failing test's screenshot is shown on the step that threw.

Gherkin scenarios, with nothing to do

A pytest-bdd scenario is already a list of named steps, so its Given / When / Then arrive on their own — each timed, each carrying what its parser pulled out of the line, and badged as Gherkin so a specification never reads as somebody's plumbing. The feature, the scenario and the feature file are named above the tree, an Outline's <placeholders> are shown filled in with the row that actually ran, and the scenario's tags arrive as markers. pytest-bdd does not have to be installed: the hooks are declared optional, so a run without it is untouched.

Markers, and where they were written

Markers are shown in full, including the ones a test never mentions: a module-level pytestmark, a marker on the class, one added by request.node.add_marker while the test ran. Each says which scope it came from, which is the answer when nobody remembers applying it. pytest's own markers are coloured apart from yours, because skipif changes how a test runs and @smoke only names it. Two are cut down deliberately: parametrize shows its argument names rather than every row the test will ever run with, and a skipif condition — evaluated at import, so it reaches any reporter as a bare False — is shown as its reason instead.

Traceability: owners, severities and markers that link

A marker holding an id is already collected and already shown, but as a flat badge — nothing in the report knows that PROJ-123 is an issue rather than a word. A pattern is the missing half. Name a marker in report_link_pattern, put {} where its argument goes, and every test carrying it gets a badge that opens the ticket.

[pytest]
report_link_pattern =
    jira = https://acme.atlassian.net/browse/{}
    testcase = https://acme.testrail.io/index.php?/cases/view/{}
    owner = https://github.com/orgs/acme/teams/{}

@pytest.mark.owner("payments-team")
@pytest.mark.severity("blocker")
@pytest.mark.jira("PROJ-123")
@pytest.mark.jira("PROJ-987")          # two tickets, two badges, one row
def test_refund_is_idempotent():
    ...

• Ids are grouped under the marker they were written asA Jira row and a Testcase row each say which system their ids belong to, so the badges themselves stay as short as PROJ-123. A test that closes two tickets gets two badges in one row.
• owner answers who do I tellIt gets a row of its own ahead of the tags rather than sitting among smoke and slow, and it is a filter: once anything carries one, the Test Steps rail grows a row of per-team pills, counted, busiest first, with an Unowned pill at the end.
• severity is a ladder, not a tagAllure's five words, worst first — blocker, critical, normal, minor, trivial. One test, one level: the nearest marker wins, two at the same scope are read as the worse of them, and the overridden one is still shown struck through with a tooltip saying where each was written. A test nobody rated is unrated, not normal.
• The ids reach the JUnit xml tooAs <property> elements on the testcase, which is the half Xray, Zephyr and TestRail actually read — none of them opens an html report. The property name is the marker name, so a suite that must emit test_key writes @pytest.mark.test_key and gets exactly that. Only owner, severity and the markers you named are written, so nothing starts appearing in a file your CI parses without having been asked for.
• Nothing is fetched and no token is neededA report is a static file that gets mailed, published and opened off a disk months later, and a badge that needs credentials is blank in exactly those cases. Ids are percent-encoded on the way into the url, and a scheme the report will not render is dropped rather than linked.
• All three markers are registered with pytestSo --strict-markers accepts them and no run prints PytestUnknownMarkWarning for a marker this plugin asked you to write. The pattern markers are registered from your configuration, because which names mean something is your decision.

Test steps, Gherkin and markers in full — including --report-steps, --report-step-limit, and what a retry reports.

Evidence: screenshots, attachments and captured output

Three different kinds of "what actually happened", each kept against the test that produced it.

Screenshots, taken for you

A test that fails while holding a Selenium driver or a Playwright page is photographed. No hook to write, no fixture to add, nothing to import. The picture is taken at the very end of the test, before the fixture that quits the browser has run. What makes something a browser is that it can hand over a PNG, so Selenium, Playwright, appium, splinter and a driver wrapper of your own are all covered, whatever the fixture is called — page, driver, browser, selenium or anything else. A test driving two browsers at once gets a picture of each.

def test_checkout(page):
    page.goto("/cart")
    assert page.locator("h1").inner_text() == "Cart"     # fails, and is photographed

Every screenshot lands in two places: the Screenshots gallery, and the Screens column of the row it belongs to. --report-screenshots decides which tests are photographed — failed by default, all if a screenshot of a pass is a baseline worth having, none to switch it off. When the moment matters, attach takes the PNG bytes yourself, from anything that can produce one; an image you attached is always kept whatever that flag says, and a test that attaches its own is not photographed again on the way out.

Attachments and API logs

A picture is no use when the thing under test is an API. attach_text, attach_json, attach_api and attach_file take the payloads instead, and everything a test hands over is opened from the API Logs tab.

from pytest_html_reporter import attach_api, attach_file, attach_json, attach_text

attach_api(requests.get(url))                         # the whole call
attach_json({"expected": order, "got": response})     # pretty-printed, secrets blanked
attach_text(query, name="Query", format="sql")        # any text at all
attach_file("payloads/order.json")                    # a small file from disk

• The curl command comes with itAn attached call holds the response body, the request body, both sets of headers, and the curl command that repeats it — the first thing anyone does with a failed request, and the tedious thing to rebuild by hand from a report.
• Credentials are blanked outAuthorization, Cookie, Set-Cookie and any name containing token, secret, password, api-key or x-auth become <redacted> — in the headers, in the curl command, in a JSON body at any depth, and in a query string. A report is a build artifact; it gets published. redact=False opts out.
• No client library is importedIt is the returned response that is passed, not the client, so requests and httpx both work out of the box — and so does the async one. Every field can also be given directly, and an explicit one always wins over the response object.
• Evidence survives a green retryA test retried by pytest-rerunfailures that attaches nothing on the attempt which finally passed keeps what the failing attempt attached, rather than losing the evidence by succeeding.

Captured stdout, stderr and logging

Everything pytest captures while a test runs — from setup, call and teardown alike — is kept against that test, and this is on by default. The Logs column shows how many lines a test produced; clicking it opens the output section by section with a Copy button.

So a test that only asserts has nothing to show and correctly gets a dash, even when it fails. Two of pytest's own options decide what reaches the column at all: -s (that is, --capture=no) sends stdout and stderr straight to the terminal so nothing is captured, and logging is captured from WARNING up unless --log-level lowers it.

Screenshots in full covers the automatic capture, the async and unittest cases, and taking the picture yourself. The Python API documents all six functions — attach, attach_text, attach_json, attach_api, attach_file and step — with every argument each one takes.

Coverage

Run with pytest-cov and the report grows a Test Coverage tab: the overall percentage as a ring, the counts beside it, a row per file with its missing lines, and the percentage plotted across this run and the five builds before it. A chip on the Dashboard shows the figure and crosses to the tab. Nothing needs configuring — if coverage was measured, it is there.

$ pytest tests/ --cov=my_package --html-report=./report
$ pytest tests/ --cov=my_package --cov-branch --html-report=./report

• The number is coverage.py's ownTaken through its public API, so the tab and your terminal always agree. With --cov-branch on, branch coverage is folded in exactly as pytest-cov folds it in and the table gains a Branches column; without it, that column is dropped rather than filled with zeroes.
• The ring takes the project's own barGreen at 90% and above, amber at 75%, red below — unless --cov-fail-under has stated a line, in which case that is where the colour is drawn and the tab says so. A report should not disagree with the build that just passed or failed beside it.
• Least covered firstThe order worth reading, and the only defensible way to shorten the list on a large project. --report-coverage-limit sets how many files are listed.
• It travels with the archivesThe percentage is written into output.json beside the test counts, which is what gives the tab its +0.8 since the last build and its trend line. A build that ran without coverage leaves a gap in that line rather than a drop to zero.

Coverage that was measured somewhere else

The tab does not need pytest-cov to have run in this session — useful in CI, where coverage is often produced by an earlier step. The kind of file is worked out from its contents, not its name, and a coverage.json or Cobertura coverage.xml sitting beside the report or at the project root is found without being named at all.

$ pytest tests/ --report-coverage-file=coverage.xml     # Cobertura, from `coverage xml`
$ pytest tests/ --report-coverage-file=coverage.json    # from `coverage json`
$ pytest tests/ --report-coverage-file=.coverage        # coverage.py's own data file

The annotated source is linked, never embedded: generate htmlcov/ with --cov-report=html and the tab links to it, and only when that folder was written by this run. Framing it into the page would break the one property the whole reporter is built on — one file you can mail — and it would break silently, showing an empty frame wherever the folder did not travel with it.

History and archives

Every run archives its own record, and the Archives section lists them. That file is what Trends, Highlights, the failure delta, the coverage trend and the whole Analytics tab are built from: it holds the test counts, a status and a duration per test, and the coverage percentage.

A build is dated by the moment its run started, which is kept in the name of its archive file — not by the file's mtime, which in CI is the moment of the checkout. That is what lets an age limit still measure the right thing after the reports have been copied into a fresh workspace.

$ pytest tests/ --archive-count 7                  # keep the last N builds
$ pytest tests/ --archive-days 30                  # a rolling window; fractions allowed
$ pytest tests/ --archive-since '2026-06-01 09:00'  # a one-off cut

The three intersect: a build has to satisfy every limit you set to be kept. Set none of them and every build is kept for ever, which is what eventually makes a report slow to open — a retained build costs roughly 5KB of the page, so an hourly run reaches a multi-megabyte report inside a couple of months. How far back Analytics reads is whatever these three have kept.

One name for a whole shape of a run

On a laptop you want the browser to open, every log kept and a handful of builds archived. On CI you want no browser, logs only where something failed, a JUnit xml beside the report and a month of history. Kept as two long invocations — one in a Makefile target, one in a workflow file — they drift the moment either is edited, and the drift stays invisible until somebody reads a report missing the thing they went looking for.

[tool.pytest-html-reporter.profiles.local]
open = "auto"
logs = "all"
archive_count = 10

[tool.pytest-html-reporter.profiles.ci]
open = "none"
logs = "failed"
junit = "report/junit.xml"
archive_days = 30

$ pytest tests/ --report-profile=ci

Both files are read, so a repository that keeps a pytest.ini does not have to grow a pyproject.toml to say ci in a single word. A profile can be pinned as the default, so a bare pytest is already the shape the repository agreed on; a PYTEST_HTML_REPORTER_* variable overrides one setting for one job without editing a file everybody else reads; and a flag typed on the command line still beats all of it.

• A typo fails the run, not the reportlogs = "fail" is a typo rather than a setting. It stops the run at configure time with one line naming the file, before a test is collected — instead of falling through to all and keeping every log because six letters were typed instead of seven.
• The report says which shape it isThe Environment panel carries a Profile row, so a report found on a CI server months later answers "where did the logs go" itself.
• And you can ask before you runpytest-html-reporter config prints every setting a run here would resolve, which layer decided it and which layers it overrode — running nothing. --report-show-config prints the same table in the pytest header of a real run.
• Nothing else changedA profile is written onto the very options the flags parse into, so an xdist worker is shaped by the same profile the controller is, and a suite that names no profile runs byte for byte the report it ran yesterday.

See Configuration for where profiles are written, what the 27 settings are called, and the six layers in order.

Running at scale

Parallel runs with pytest-xdist

Runs distributed with pytest-xdist are gathered into a single report. Every worker sends its results back to the controller, which merges them and writes one report — one build in Archives, one set of totals, one row per test — whichever way the tests were distributed. Tests are listed in collection order rather than the order the workers happened to finish them in, so a parallel report reads the same as a serial one. Nothing needs configuring, and running without -n is unaffected.

$ pytest tests/ -n 2 --html-report=./report
$ pytest tests/ -n auto --dist loadfile --html-report=./report

The strftime placeholders in --html-report are expanded once, when the run starts, which is what lets a parallel run — and a run that crosses a minute boundary — still write a single report.

Reruns

The plugin reacts to pytest-rerunfailures; there is no rerun-specific flag to set. A retried test is one row carrying the outcome that stuck, with the attempts it took in the Rerun column.

Two more behaviours are worth knowing, and they deliberately differ:

• Attachments survive a green retryA test that attaches nothing on the attempt that finally passed keeps what the failing attempt attached, rather than losing the evidence by succeeding.
• Steps report the attempt that stuckThe failing attempt's tree beside a green test would describe a run that did not happen.

Analytics counts retries too: a test that needed one to pass is flaky by definition, and the per-test row carries a retries column.

Matrix runs

pytest-xdist merges within one run, so a CI matrix — several processes on several machines — is out of its reach. Name each leg with --report-shard instead: it writes a bundle to <report>/shards/<id> and no report of its own, and the standalone pytest-html-reporter merge command turns every bundle into one build once the legs have finished. Legs that run one after another on a single machine can skip the extra command — give the last one --report-shard-merge and it merges as it ends.

Each leg still needs its own artifact name to get its bundle off the runner. The GitHub Action takes an artifact-name input for exactly this, and a build-info entry is the place to record which leg of the matrix a record came from. The CLI reference has the four shard flags and the merge command's own options.

CI integrations covers the rest: keeping the archive folder between runs so the trend charts have something to draw, and publishing the report where people will actually open it.

The ecosystem

The GitHub Action

A composite action that installs the plugin, runs pytest and publishes what comes out. Its inputs mirror the plugin's flags one for one — report-path, title, environment, build-info, archive-days, report-logs, report-coverage and the rest — plus the parts that only make sense on a runner.

name: tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: prashanth-sams/pytest-html-reporter-action@v1
        with:
          python-version: '3.12'
          requirements: requirements.txt
          tests: tests/
          title: Nightly regression

• In the job summaryThe headline, the counts, the failures with their messages up to failure-limit, the suites ranked by damage, the slowest tests, and coverage when the run measured any — without clicking through to an artifact.
• On the pull requestThe same summary as one comment that is updated on every push, rather than a new comment each time.
• History across runshistory: 'true' carries the archive/ folder between runs with the Actions cache, so Trends, Archives and Analytics have more than one build to show on a fresh runner.
• Gates and outputsmin-pass-rate and min-coverage fail the job on a threshold, fail-on-empty catches a mistyped -k that would otherwise go green, and around twenty outputs — passed, failed, pass-rate, coverage, status — let a later step post to Slack, open an issue or gate a deploy.

The GitHub Action in full — every input, the recipes for a pull-request comment, a coverage gate and a Pages deploy, and the outputs a later step can read.

The VS Code extension

The same results in the sidebar, while you are still in the file that broke. It reads output.json rather than the generated HTML, finds the report on its own, and reloads when a run finishes.

• Failures at a glance, and one click to the testEvery failing test grouped under its suite with a truncated error on the card; clicking one opens the file at the test's def. Copying gives you the original error, terminal colouring intact.
• Flaky vs brokenPast builds in archive/ are read to tell a test that sometimes fails from one that has never passed. Stable tests get no badge, so the ones that do mean something.
• The full report in an editor tabSteps, Attachments, Analytics, Coverage and screenshots, opened in VS Code instead of a browser — and a dropdown to switch between several reports.

The VS Code extension in full — where it looks for your report, what each setting does, and the layout it expects on disk.

Where to go next