Skip to content

Vuetify is installed in the unit runner #1083

Description

@ExtraToast

Parent

#1095

What to build

Vuetify is installed in the frontend unit runner, so a unit test can see what a reader sees.

Today the unit suite installs no Vuetify instance. A <v-...> element resolves to nothing, the setup file swallows the "failed to resolve component" warning that says so, and a hand-written $vuetify object stands in for the breakpoints and theme a real instance would compute. 103 of the 132 single-file components use Vuetify elements, so anything rendering through one of their slots is invisible to a unit test and gets pushed into Playwright instead. Roughly 29% of the end-to-end suite is pure logic with nowhere else to go.

This is step 1 of testing ADR-005, which names the change, requires the warning suppression to be removed with it, and says plainly that the suite will turn red: "that is the defect surfacing, not a regression."

Measured on a scratch branch, with the previous ticket's shims already in place, the residue is about a dozen files in three shapes. A handful of tests are shallow-mounted and were only ever passing because an unresolved element leaked its children through; they mount properly now. A handful assert on markup that exists only while a component is a stub — a literal v-btn tag, a badge's prop read back as a DOM attribute, a router link's to — and now assert on what is actually rendered. Three replace the whole Vuetify module with a stub rather than spreading the original, and have to keep the parts the plugin needs.

Per-test breakpoint overrides go the same way as the global one. Four exist across three files and only one is load-bearing: a banner with a genuine mobile branch. That one resizes the window, which is what the real breakpoint code reads; the other three are copies of the global values and are deleted.

The suite goes from 31 to 43 seconds. The cost is building an instance per worker file, and it buys a runner where no test fails for a component nobody registered.

Coverage stays on the v8 provider and its numbers will move once components really render. Moving to istanbul is ADR-005's step 2 and is deliberately not in this ticket.

Acceptance criteria

  • The unit runner installs a real Vuetify instance for every mount, configured like the application's own
  • The hand-written $vuetify stand-in is gone, and breakpoints come from the window, with the default viewport chosen so existing tests keep the meaning they had
  • The "failed to resolve component" suppression is gone, and no such warning is emitted anywhere in the run
  • A test that wants a phone resizes the window rather than describing one
  • Tests that asserted on stub markup assert on rendered output instead
  • yarn test:unit, yarn lint and yarn typecheck each exit 0, verified by exit code
  • The pull request records the new suite duration, so later work is judged against it
  • Test files that stub a Vuetify component by name are left alone: removing one changes what its test proves and is a separate decision

Blocked by

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready-for-agentSized and specified for an agent to pick up

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions