test: coverage expansion beyond #63 — done; what was left is upstream's or reka-ui's

[IgorShevchik]

Closed as done. All five workstreams are worked through — three by writing tests, two by measuring them away. Coverage went 71.89% to 74.95% of statements over four PRs, and three defects turned up along the way. Figures below, so the next audit does not re-file the parts that were declined.

---

What was done

PR	what
#519	eleven of the thirteen components that are ours and had no coverage: PageCardGroup, SidebarLayout + six wrappers, Navbar + three
#521	ModalDialogClose, the twelfth; plus utils/overlay.ts, utils/link.ts, utils/content.ts
#522	the two keyboard paths we hand-wrote: CommandPalette's Backspace, FileUpload's Enter/Space

Coverage: 71.89 → 74.95% statements, 69.93 → 72.10 branches, 71.19 → 74.04 functions, 71.44 → 74.47 lines.

Defects found while writing them

• SidebarLayout rendered data-state="isLoading ? 'loading' : 'show'" as a literal string — the binding was missing its colon, so every layout put the source of the expression into the DOM. Fixed in test: cover the eleven components we wrote that nothing tested #519.
• offContentScrollbar is a public prop on SidebarLayout that does nothing: both branches of its variant are empty strings and the one compound reading it has its class block commented out. Reported, not fixed — it is a decision about public API shape.
• Earlier in the same sweep, fix(types): stop advertising isAction on components that cannot honour it #517 removed isAction from ten types that advertised it and could not honour it.

The measure that changed everything

"Has no spec file named after it" is not "untested", and it overstated every count in this issue. Two better measures:

Is it imported by any spec? 68 of 182 components were not — but 55 of those exist in nuxt/ui@v4, where they have no specs either. Thirteen were ours. Those thirteen were the real gap, and twelve are now covered (ModalDialogClose was the last testable one).

Is it executed? For src/runtime/utils, coverage answered directly: prototype-guard.ts looked like the prize — 81 lines, entirely ours, closing two prototype-pollution holes — and was already at 100%, exercised through get/set and getAtPath/setAtPath.

What was declined, and why

Locale key-parity. Measured: all 20 locales carry the same 78 keys, no missing, no extra. And they have never drifted — src/runtime/locale/en.ts has been touched by exactly one commit in the repository's history, which changed all 21 locale files together. A guard here would be a guard for something that has not happened.

Most of the keyboard workstream. It reads as a large gap — arrow keys, Home/End, Escape across menus, tabs, accordion, palette, pagination. All of that is reka-ui's roving focus and typeahead. Five places in src/runtime handle a key themselves; three already had specs, and the two that did not are covered by #522.

Upstream components and composables. 55 components and most of the remaining utils. The rule settled with the maintainer: we do write tests for code we ship but did not write — a test lives in test/ and does not diverge from upstream the way a rewrite does — but filtered to what a user can see. Under that filter, three utils qualified and are done. ai.ts (streaming-state predicates, visible only inside a chat UI), virtualizer.ts (71%, the rest is measurement arithmetic) and editor.ts (12% of 587 lines) did not.

Still open elsewhere

• 13 composables have no spec. Most are thin; none surfaced as a risk during this sweep. Worth revisiting only if one of them breaks.
• editor.ts at 12% is the largest single uncovered surface left. refactor(Editor): the command-handler debt is upstream's, not ours — not diverging for it #88 closed as not-planned for rewriting it; testing it is a separate question and a slice of its own.
• offContentScrollbar needs a decision.

Priority: was P2.

---

Original text, June 2026

1. Components without any spec — 76 of 178

• 24 top-level: App, ContextMenuContent, DropdownMenuContent, EditorEmojiMenu, EditorMentionMenu, EditorSuggestionMenu, Empty, LinkBase, ModalDialogClose, Navbar, NavbarDivider, NavbarSection, NavbarSpacer, OverlayProvider, PageCardGroup, Sidebar ×8 (see the vitest-globs bug issue), Toaster.
  • *Content/LinkBase are partially exercised via parent specs, but Toaster, Empty, Navbar family, PageCardGroup, App are user-facing with zero coverage. Toaster + untested useToast means the entire toast lifecycle (queueing, auto-dismiss timers) is untested.
• 46 of 47 prose components (only ProsePrompt has a spec), all 5 color-mode/*, locale/LocaleSelect.vue.

2. Composables — 5 of 24 tested

Tested: defineShortcuts, useComponentProps, useEditorMenu, useOverlay, useScrollShadow. Untested logic carriers: useFormField, useToast, useFileUpload, useFilter, useKbd, useLocale, useIMEGuard, useResizable, useScrollspy, useSpeechRecognition, usePortal, useConfetti, useDevice, useFieldGroup, useForwardProps, useAvatarGroup, useComponentIcons, useContentSearch, defineLocale.

3. Utils — 2 of 12 runtime modules touched

Untested: ai.ts, content.ts, dashboard.ts, editor.ts, fuse.ts (see the XSS issue — needs a regression test anyway), link.ts, locale.ts, overlay.ts, tv.ts (the theme merge engine!), virtualizer.ts; plus all 4 build-time src/utils/*.

4. Locale key-parity (cheap, high value)

20 locale files in src/runtime/locale/, no test validating completeness. A ~10-line it.each comparing flattened keys of each locale against en.ts catches missing/extra keys on every locale PR.

5. Keyboard interaction is essentially nil

keydown/keyup appears in only 2 spec files (ChatPrompt.spec.ts, composables/defineShortcuts.spec.ts). No arrow-key/Home/End/Escape tests for menus, tabs, accordion, palette, pagination. Specifics beyond #63: CommandPalette.spec.ts (185 lines) has zero trigger/emitted/setValue — no filtering/selection/highlight tests even though #76 fixed a highlight bug there; Editor.spec.ts is 29 lines for the richest component in the kit; #63's behavioral starter set is half-done (Select/SelectMenu ✅, Accordion and Modal still none).

Form.spec.ts (728 lines: zod/yup/joi/valibot, nested forms, touched/dirty) is the in-repo model to copy.

Priority: P2 — the sync pipeline's safety net (#75) is only as good as this coverage. Suggest tackling top-down: Toaster/useToast → useFormField/useFilter/tv.ts → locale parity → keyboard set.

[IgorShevchik]

Inventory update after PR #335, which fixed the vitest-glob bug (#83) this issue's §1 refers to. Two entries here are now done, and the fix surfaced three items worth adding.

Closed by #335

• Empty — the spec had been deleted by 2e9e78a0 (the only spec that commit removed) while Empty.vue kept shipping, leaving orphaned snapshots behind. Restored, carried to renderEach, extended with the loading prop it grew in the meantime. A history sweep confirmed no other spec was ever deleted while its component survived.
• Sidebar — test/Sidebar.spec.ts existed but sat at the test/ root, which no project's include pattern reached, so it had never executed. Moved to test/components/, now runs in both projects.

Still open from §1, with a correction

The "Sidebar ×8" line counted the whole family. Only Sidebar itself is covered now; the seven sub-components still have no spec: SidebarBody, SidebarFooter, SidebarHeader, SidebarHeading, SidebarLayout, SidebarSection, SidebarSpacer.

Current full list of top-level components with no spec — 22, down from 24:

App, ContextMenuContent, DropdownMenuContent, EditorEmojiMenu, EditorMentionMenu, EditorSuggestionMenu, LinkBase, ModalDialogClose, Navbar, NavbarDivider, NavbarSection, NavbarSpacer, OverlayProvider, PageCardGroup, SidebarBody, SidebarFooter, SidebarHeader, SidebarHeading, SidebarLayout, SidebarSection, SidebarSpacer, Toaster

New: coverage that exists but does not assert what its name says

Two of these came out of reviewing #335 and belong with the rest of the inventory:

1. Sidebar's mode cases are vacuous. test/components/Sidebar.spec.ts renders with mode modal, with mode slideover and with mode drawer, but the dialog content is behind v-if="isMobile" (Sidebar.vue:140,358), driven by useMediaQuery('(max-width: 1023px)'), which never matches at either test environment's default viewport. All three snapshots are byte-identical, mode-agnostic shell markup. The case names promise coverage that is not there. Fix: stub the media query so the mobile branch renders, then regenerate.

2. Nothing in the suite can assert a laid-out dimension. ChatMessages.updateLastMessageHeight() computes lastMessageHeight from getBoundingClientRect() and element offsets; happy-dom lays nothing out, so every such value is 0 and the new test in fix: four silent defects from the June 2026 audit (#79, #80, #81, #83) #335 can only assert "no observers leak", never "the number is right". This affects any future work on --last-message-height, useResizable, useScrollShadow and the virtualizer. Fix needs a real layout engine — the repo already has Chromium and Puppeteer available, so a small browser-backed spec project is plausible; that is a decision, not a chore, and it overlaps test: three coverage gaps left after #313 — module setup(), platform.ts SSR branch, and nothing that boots the package #329.

3. The vue project skips two component directories by design now. components/content/** and components/nuxt/** are excluded because those surfaces do not exist in the Vue build (src/plugins/components.ts drops content/*.vue; LinkLocale.spec.ts needs #imports). Not a gap to close — recorded here so the numbers in this issue stay honest.

A guard added in #335 (test/utils/vitest-include.spec.ts) now fails if any spec is collected by zero projects, runs in only one for an undocumented reason, or leaves a snapshot behind without a spec. So the silent half of this issue is handled; what remains is the inventory itself.

---

Generated by Claude Code

[IgorShevchik]

One more gap for the inventory, found during the review of PR #338 and worth recording where the rest of the coverage debt lives.

The useContentSearch → sanitizeSnippet → DOM path is untested end to end

src/runtime/composables/useContentSearch.ts:139-148 builds labelHtml and descriptionHtml from sanitizeSnippet() and hands them to CommandPalette, which renders them with v-html. ContentSearch.vue is the only place in the repo that sets includeMatches: true, so this is the one path where those bindings are genuinely live in production — and the values come from indexed document content, which is the most attacker-influenceable input the kit handles.

Nothing tests it:

• there is no useContentSearch.spec.ts at all;
• test/components/content/ContentSearch.spec.ts covers debounce and prefix-building, with no escaping assertions;
• test/utils/search.spec.ts unit-tests sanitizeSnippet()/highlight() thoroughly, but as pure functions — nothing connects their output to a rendered DOM.

PR #338 added cases that drive all three v-html bindings with a hand-written highlighter-shaped string, which covers the sink. What is still missing is the wiring: a malicious snippet going in one end of useContentSearch and coming out inert in ContentSearch's DOM.

Related, from the same review: the real Fuse-driven path is also untested. Mounting with fuse: { fuseOptions: { includeMatches: true } } and a matching searchTerm was verified by hand to produce <mark> around the match while escaping an embedded <img> — correct behaviour, asserted nowhere.

Two tests would close both: one integration case on ContentSearch with a snippet payload, and one on CommandPalette with includeMatches enabled.

---

Generated by Claude Code