test(stringified-props): scan the corpus once, outside the timed test

[IgorShevchik]

Linked issue

None — this fixes a defect introduced by #545, found by it going red on an unrelated branch.

Type of change

• Documentation (updates to the documentation or readme)
• Bug fix (a non-breaking change that fixes an issue)
• Enhancement (improving an existing functionality)
• New feature (a non-breaking change that adds functionality)
• Chore (updates to the build process or auxiliary tools and libraries)
• Revert (undoing a merged change — retitle this PR revert(Scope): ...)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

The guard added with #545 read all 218 snapshot files inside its it(), so 28 MB of I/O sat under vitest's 5-second per-test default.

where	cost
plain node, standalone	~0.5 s
the nuxt project, file run alone	1.9 s — 38 % of the budget with zero contention
full run, sharing forks with 346 other files	past 5 s → timeout

FAIL |nuxt| test/utils/stringified-props.spec.ts > leaks no object-valued prop into the corpus as an attribute
Error: Test timed out in 5000ms.

Not a leak — a direct grep over the corpus returns zero [object Object] either side of this change.

The fix is the pattern already next door

indistinguishable-snapshots.spec.ts does the same 28 MB read and does not flake, because it does it in the describe body:

describe('snapshot entries that are indistinguishable from a sibling', () => {
  const current = collectGroups()   // outside it(), so no per-test timeout

This file now does the same. The corpus is read once instead of once per assertion, and the assertions are free.

It timed out twice; the first time went unnamed

The first occurrence was reported as an unexplained single failure during #549 — one test, one project, and three clean re-runs afterwards. The log had been captured as a tail so the test's identity was lost, and I said at the time I would not call it flaky without a name. This is the name, and the shape matches: one test, one project, intermittent, load-dependent.

Verifying the guard still bites

Appended an [object Object] attribute to Badge.spec.ts.snap; it reds in both projects and names the file and the attribute:

+   "components/__snapshots__/Badge.spec.ts.snap: leaked=\"[object Object]\"",

Worth recording that the first attempt at that mutation stayed green and the guard was briefly under suspicion. The cause was printf escaping the quotes, so the injected text never matched a pattern that was working correctly. A mutation that fails to go red is a claim about the mutation before it is a claim about the test — the mirror of the lesson from #529, where a mutation went red for the wrong reason.

Checks

• pnpm lint green
• Full suite green on two consecutive runs: 347 files, 7903 passed, 6 skipped
• Guard verified red under an injected leak, in both projects; corpus restored from a copy rather than git checkout --

Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

🤖 Generated with Claude Code

https://claude.ai/code/session_012MsMuj8Fic9tjWVjyEyrxc

---

Generated by Claude Code