Unit test coverage above 60%
Why it matters
Having test files is necessary but not sufficient — a test suite that only renders components without crashing and ignores business logic in src/lib/ provides false confidence. ISO 25010:2011 §6.5.5 requires that reliability verification covers the critical paths. A payment calculation function, a permission check, or a data transformation that is never tested will eventually receive a change that breaks it; without a coverage gate, no one learns about it until a user reports a wrong order total or a privilege escalation.
Severity rationale
Medium because low unit coverage means business logic changes ship without regression verification, turning every refactor into an undetected risk for production correctness.
Remediation
Prioritize business logic over UI rendering — pure functions in src/lib/, src/utils/, and src/services/ are the highest-return coverage targets. Enforce a minimum in your test config:
// vitest.config.ts
import { defineConfig } from 'vitest/config'
export default defineConfig({
test: {
coverage: {
provider: 'v8',
thresholds: {
lines: 60,
functions: 60,
branches: 50,
},
exclude: ['**/*.config.*', 'src/app/**', 'src/components/**'],
},
},
})
Run npx vitest run --coverage to see your current baseline before writing new tests.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Code Quality Essentials Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.testability — Maintainability — Testability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from code-quality-essentials·automated