When working with pytest locally, the loop after a test failure usually looks like this:
- run tests
- scan terminal output
- find the failed test
- locate the file
- scroll to the failure
- repeat if there are multiple failures
It works, but it’s not particularly calm — especially when failures are spread across files or when you’re re-running tests frequently.
As part of maintaining pytest-html-plus, we’ve been thinking about how to make the local fix loop a little smoother — without introducing new concepts or replacing existing tools.
We’ve taken a similar approach before with the GitHub Actions integration: instead of asking users to learn a new workflow, the action simply plugs into existing CI YAML and publishes the same report artifact automatically.
Along the same lines, we’ve been experimenting with a small VS Code extension that:
- reads the generated report
- surfaces failed tests in a sidebar
- lets you jump directly to the failure location in code
One deliberate design choice is that the extension does not try to run or discover tests.
Instead, it consumes a stable artifact — final_report.json — produced by pytest-html-plus.
That means it doesn’t matter:
- where pytest was run (terminal, CI, container, xdist, docker etc.)
- how the tests were executed
- whether they ran inside or outside the editor
- As long as a report exists, the extension can surface failures and navigate to their source.
This keeps the extension:
- runner-agnostic
- predictable
- decoupled from test execution itself
What we added
We’ve released a small VS Code extension that focuses on one thing:
helping you stay in the editor while fixing failures, and only switch to the HTML report when you actually need it.
The extension reads the existing generated report produced by pytest-html-plus and presents:
- a quick summary (passed / failed / skipped)
- failed tests grouped by file
- inline error context
- one-click navigation to the failure line
There’s no test execution, no report rendering, and no screenshots in the editor.
What this extension is not
This is important to be clear about.
The VS Code extension does not:
- replace the HTML report
- render screenshots or CI artifacts
- analyze failures
- re-run tests
- change how pytest works
- Try to be just another extension to run pytest and show results
The HTML report remains the source of truth for:
- detailed inspection
- screenshots
- metadata
- CI usage
The extension is intentionally scoped to local development, when the goal is simply to move from failure → fix as quickly as possible while already inside the editor.
Why we kept it small
There’s a temptation to turn editor extensions into dashboards.
We resisted that.
Instead, the extension is designed to:
- complement the terminal, not replace it
- respect existing workflows
- stay out of the way when you don’t need it
- You open it when you want orientation.
- You close it when you don’t.
Configuration, on your terms
The extension supports a few lightweight ways to configure the report path:
- browse for the report file
- enter the path manually
- auto-detect reports in the workspace
- Nothing is auto-configured without asking, and nothing is mandatory.
Where this fits in the ecosystem
With this addition, the pytest-html-plus ecosystem now looks like this:
- Core library → generate a unified report (local + CI)
- GitHub Action → publish reports automatically in CI
- VS Code extension → act on failures locally, inside the editor
Each piece does one thing, at one moment, for one context.
If your workflow already feels smooth with the terminal alone, you may not need this.
But if you often:
- deal with multiple failures
- jump between test files
- re-run tests while iterating locally
this extension might reduce a bit of friction in that loop.
As with the rest of pytest-html-plus, the goal isn’t to change how you work — just to remove a few unnecessary steps.
Links
VS Code extension: Pytest HTML Plus
Core library: pytest-html-plus
Github actions: pytest-html-plus
Top comments (0)