DEV Community: Joris Gallot

Tracking component health over time with Vitest browser mode and Storybook

Joris Gallot — Sun, 11 Oct 2026 16:00:45 +0000

Component tests have become real browser tests. Vitest browser mode runs them in Chromium through Playwright, and Storybook's Vitest addon turns every story into a test. They are fast, they render the real thing, and most design systems now have hundreds of them.

What they still lack is memory.

A run tells you that 3 tests failed out of 400. It does not tell you:

Which components are those 3 tests about?
Was the Select story already failing yesterday, or did it break with this pull request?
Which stories fail once in a while and pass on retry?
What did the component look like when the screenshot assertion failed in CI?

The output is a list of tests. The thing you care about is a list of components.

A test is not a component

Test runners report by file and by test title. That is the right unit for running tests, but not for reading the state of a design system.

One story is often covered by several tests: a render check, an interaction, a visual assertion. One test file often covers several stories. When something fails, you have to map the test title back to a component in your head, then go look for the previous runs to know whether it is new.

Storybook already gives you the right unit, the story. Button/Primary means something to everyone on the team, designers included. So the useful question is simple: for each story, what happened in the last runs?

Sending Vitest and Storybook results to Kinora

Kinora started as a dashboard for Playwright reports. It now takes Vitest runs too, through a reporter you add next to the default one:

pnpm add -D @kinora/vitest-reporter

// vitest.config.ts
import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    reporters: ['default', ['@kinora/vitest-reporter', { project: { slug: 'design-system' } }]],
  },
})

Then run your tests with an API token in the environment:

KINORA_TOKEN=<token> npx vitest run

Three things are worth knowing about how it behaves.

It uploads browser tests only, by default. Node unit tests are usually thousands of fast, deterministic tests with no trace. They add little to a dashboard, so the reporter skips them unless you set include: 'all'.

With Storybook's Vitest addon, there is nothing else to do. Each story is already a Vitest test, and the reporter records which story each test renders, as <Component>/<Story>.

An upload never fails your test run. If the server is unreachable, your tests still pass or fail on their own merits.

One page per design system

Once a run with stories is uploaded, the project gets a Components page. Stories are grouped by component, and each story shows:

its latest status
a timeline over the last 20 runs
the tests that render it

A story's status in a run is the worst status among its tests in that run. If the render check passes and the interaction test fails, the story is failing.

The timeline is what changes the conversation. A story that is red in the latest run and green in the 19 before it is a regression, and the pull request is the suspect. A story that goes red every few runs is flaky, and the pull request is probably innocent. You can tell the two apart in a glance, without opening a single CI log.

What it looked like when it failed

History tells you when a story broke. You still need to see why.

With the Playwright provider, Vitest browser mode can record a Playwright trace per test:

import { playwright } from '@vitest/browser-playwright'
import { defineConfig } from 'vitest/config'

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      provider: playwright(),
      instances: [{ browser: 'chromium' }],
      trace: 'retain-on-failure',
    },
  },
})

The reporter uploads the trace.zip of each failing test, and Kinora opens it in its embedded trace viewer: DOM snapshots, console, network, right from the failed test. No artifact to download from CI.

Visual assertions get the same treatment. A failing toMatchScreenshot uploads its reference, actual and diff images, and the run page shows them as a screenshot comparison. You see the two pixels of padding that moved before you even check out the branch.

Not on Vitest? Playwright component tests work too

If your component tests run on Playwright's own mount fixture, they already upload like any other Playwright test. The only missing piece is which story a test mounted, and one import records it:

import { expect, test } from '@kinora/reporter/ct'

test('disabled button is disabled', async ({ mount }) => {
  const component = await mount('Button/Disabled')
  await expect(component.getByRole('button')).toBeDisabled()
})

Stories from both paths land on the same Components page. This is the setup I use for Kinora's own design system, and the component testing guide has the full Vue and Vite example to copy.

Two limits to know about

A test that renders several stories counts for each of them. Kinora knows which stories a test mounted, not which one an assertion failed on. A failure marks all of them as failing. Keep one story per test when you want precise attribution.

Storybook play functions are not Playwright actions. The trace of a Storybook test shows the rendered story, not each interaction step.

Asking an agent instead of reading the page

The same data is available to coding agents through Kinora's MCP server. Its component_health tool answers questions like "which stories of Dialog are failing or flaky, and which tests render them?". That is a much better starting point for an agent than a raw test log.

Try it

If you already run Vitest in browser mode or Storybook tests in CI, the setup is one dependency and one line in your config.

Introducing Kinora: a Playwright test dashboard with history, flaky tracking, and traces

Joris Gallot — Mon, 05 Oct 2026 17:38:23 +0000

Playwright gives you an excellent HTML report for a single test run. You can open a failed test, inspect screenshots, read errors, and launch the trace viewer when you need the full story.

That works great when you are looking at one run.

It gets harder when your team wants to answer questions across many runs:

Is this failure new, or has it been failing for days?
Which tests are flaky across branches and projects?
Did the pass rate improve after the last fix?
Where is the trace for the CI failure someone reported yesterday?
Can everyone on the team debug from the same place without downloading artifacts?

That is why I built Kinora.

What is Kinora?

Kinora is a dashboard for Playwright test reports across projects and over time.

CI runs push their results to Kinora. The dashboard keeps the history, tracks pass rates and trends, surfaces flaky tests, and lets you open the full Playwright trace inline from a failed test.

The goal is not to replace Playwright's report. The goal is to keep the useful parts of every report after CI finishes and make them searchable, comparable, and easier to debug as a team.

You can use Kinora in two ways:

Self-host it for free with Docker Compose.
Use the hosted Kinora cloud when you do not want to run the infrastructure yourself.

The source is available on GitHub, with MIT-licensed embeddable packages and fair-source app packages.

Why not just use the Playwright HTML report?

The Playwright HTML report is optimized for one run. That is the right default.

But CI test debugging often needs a longer memory.

A single report can tell you that a test failed. It does not naturally tell you that the same test failed three times this week, passed on main, failed only on Chromium, or started getting slow after a specific change.

Teams usually fill that gap with a mix of CI artifacts, screenshots, Slack messages, local downloads, and tribal knowledge.

Kinora keeps the run data in one place so you can see:

run history by project
pass rate trends
failed and flaky tests
retries and durations
git and CI metadata
trace.zip artifacts attached to failures

That context makes triage faster because the first question is no longer "where is the report?". It becomes "what changed?".

How it works

A typical setup looks like this:

Add the Kinora reporter to your Playwright config, or upload a results.json file with the CLI.
Run Playwright in CI like you already do.
Kinora normalizes the report and uploads the run through a simple REST API.
The dashboard stores the run, tests, metadata, and trace artifacts.
Your team opens Kinora to review the current run or compare it with history.

The important part is stable test identity.

Kinora derives a cross-run key from the test file, title path, and project name. That means the same test can be tracked over time even when it is uploaded from different CI jobs or ingestion paths.

Debugging failures with traces inline

Playwright traces are one of the best parts of the Playwright ecosystem. They let you replay actions, inspect DOM snapshots, view network requests, and understand what happened before a failure.

But traces are often trapped inside CI artifacts.

Kinora keeps the trace attached to the failed test. From the dashboard, you can open it directly in the embedded trace viewer without downloading the zip or switching tools.

That makes traces part of the team workflow instead of a local debugging afterthought.

Finding flaky tests over time

A flaky test is rarely obvious from a single run.

You need history to see that a test passes most of the time, fails sometimes, retries successfully, or fails only under one browser or CI condition.

Kinora keeps that history so flaky tests can be investigated as a pattern, not as isolated failures.

The dashboard helps you spot tests that repeatedly move between passed, failed, and flaky states. From there, you can open the run, inspect the trace, and decide whether the problem is test code, app behavior, infrastructure, or timing.

Built for CI, self-hosting, and teams

Kinora is CI-agnostic. Anything that can run Playwright and send an HTTP request can publish a run.

The reporter is convenient for Playwright projects. The CLI is useful when you already generate a report and want to upload it as a separate step.

For deployment, there are two paths:

Self-hosted: run the server, web app, Postgres, and artifact storage on your own infrastructure.
Cloud: use Kinora without managing the stack.

Self-hosting matters because test reports can include sensitive URLs, logs, screenshots, traces, and environment metadata. If you want that data to stay on your infrastructure, it can.

What is next?

Kinora already covers the core workflow: ingest Playwright runs, keep history, surface failures and flaky tests, and open traces inline.

The next steps are about making that workflow even more useful:

better artifact previews for screenshots and videos
richer local desktop workflows around traces and failed tests
stronger integrations with alerts, pull requests, and agents
more content and guides around Playwright reporting best practices

If you are using Playwright in CI and want a persistent dashboard for your test history, Kinora is available now.