test(ci): add coverage instrumentation (@vitest/coverage-v8) and a baseline threshold gate

[IgorShevchik]

Background

Surfaced during the June 2026 multi-angle project audit (QA review).

Problem

There is zero coverage instrumentation:

• no @vitest/coverage-* dependency in package.json;
• no coverage block in vitest.config.ts;
• .github/workflows/ci.yml runs install → dev:prepare → lint → typecheck → vitest run → build → two playground builds on Node 22/ubuntu only — no coverage report, no gate.

With 76 of 178 components currently spec-less (see the coverage-expansion issue) nothing stops coverage from silently eroding further, and the upstream-sync process (#75) leans on the test suite as its main safety net.

Fix

• Add @vitest/coverage-v8, configure coverage in vitest.config.ts (exclude generated/#build artifacts).
• Set thresholds at the current baseline (so CI goes red only on regression) and ratchet up over time.
• Surface the summary in the CI job output; optionally upload the report as an artifact.

Priority: P2.

[IgorShevchik]

Done in #500. The lights are on — and the first thing they showed is that the gate is narrower than any of us hoped, which is worth saying out loud.

Everything the issue asked for is in: @vitest/coverage-v8, a coverage block, thresholds derived from the baseline, the summary in the CI log, and coverage/ uploaded as an artifact. CI now runs the instrumented suite instead of the plain one — one run, not a second job, 240s → 320s.

The baseline, measured on Node 24 because that is what CI pins:

Statements   : 71.89% ( 5265/7323 )    threshold 70    headroom 198
Branches     : 69.86% ( 5134/7348 )    threshold 68    headroom 202
Functions    : 71.04% ( 1875/2639 )    threshold 70    headroom  39
Lines        : 71.45% ( 4659/6520 )    threshold 70    headroom 135

Three things that only turned up by measuring

"At the current baseline" is a trap if you take it literally. Rounding the measured numbers down to the whole percent gave functions a threshold of 69 against a measured 69.04 — one new uncovered function turned CI red, while statements tolerated 38. A factor of forty between metrics. The rule is now baseline minus a point, floored.

The number is not reproducible to the digit. Three full runs of the same clean tree gave two different denominators, and it is not the Node version — both values came out of Node 24. One fully-covered function in Button.vue appears or does not, worth about 0.01pp. Harmless against a one-point margin, and fatal against a threshold pinned to the baseline.

Scope had to shrink to mean anything. module.ts, unplugin.ts, vite.ts, plugins/, templates.ts were being counted at 0% while test/module tests them — separate config, separate process, uninstrumented. About 175 statements reported as untested that no amount of module testing could ever have fixed.

The part the issue was really worried about

nothing stops coverage from silently eroding further

This gate does not stop that, and pretending otherwise would have made it worse than useless. describe.skip on the entire Button suite — 212 tests — leaves statements, functions and lines unchanged to the digit. Button.vue is mounted by dozens of other specs, so its code keeps executing whether or not anything asserts about it.

Coverage measures execution, not assertion. What this gate catches is a large new area arriving untested — a 190-statement file with no tests goes red on functions and lines. A median 14-statement component does not. Per-file thresholds would close the gap and are blocked on 93 files sitting at 0%, which is #86's territory, not this one's.

The full write-up with the arithmetic is in the testing guide, including the one trap you will hit: pnpm run test:coverage --project vue is red by construction, because the thresholds are checked against all of src/ however little of it ran.

Thanks for filing it — "no coverage instrumentation at all" was true, and fixing it was less interesting than finding out what the fix is actually worth. 🔦

— from the repo owner

---

Generated by Claude Code