What
test/components/Table.spec.ts:73-83 defines a date column whose cell formats a value through toLocaleString:
{
accessorKey: 'date',
header: 'Date',
cell: ({ row }) => {
return new Date(row.getValue('date')).toLocaleString('en-US', { … })
}
}
None of the fixture rows have a date field. test/components/Table.spec.ts:18-49 carries id, amount, status and email and nothing else, so row.getValue('date') is undefined, new Date(undefined) is an invalid date, and every one of those cells renders the literal string Invalid Date.
It is in the committed snapshots: 10 occurrences in test/components/__snapshots__/Table.spec.ts.snap (first at line 491) and 10 more in Table-vue.spec.ts.snap.
Why it matters
The column looks like coverage of date rendering and is not. A real regression in how Table renders a formatted cell would leave Invalid Date exactly where it is and the snapshots would stay green — the same failure shape as the orphaned spec behind #83, one level down: the spec runs, the assertion is live, and it asserts nothing anyone wants.
How it was found
Split out of #84 while fixing the suite's timezone (#418). That issue claimed this line was a timezone flake source, on the reasoning that toLocaleString without an explicit timeZone renders differently per machine. It does not — because Invalid Date is Invalid Date in every zone on earth. The claim was wrong, but it pointed at a real defect of a different kind. #84 has been corrected accordingly.
Fix
Add a date field to the fixture rows (an ISO string, e.g. '2025-01-01T00:30:00Z') and regenerate the two snapshot files. With TZ now pinned to UTC by #418, the formatted output is stable across machines, so the regenerated snapshot is safe to commit.
Worth checking the other columns in the same spec for the same defect while there.
Priority: P3 — no user-facing impact, but it is dead coverage sitting in the most-referenced component spec in the repo.
What
test/components/Table.spec.ts:73-83defines adatecolumn whose cell formats a value throughtoLocaleString:None of the fixture rows have a
datefield.test/components/Table.spec.ts:18-49carriesid,amount,statusandemailand nothing else, sorow.getValue('date')isundefined,new Date(undefined)is an invalid date, and every one of those cells renders the literal stringInvalid Date.It is in the committed snapshots: 10 occurrences in
test/components/__snapshots__/Table.spec.ts.snap(first at line 491) and 10 more inTable-vue.spec.ts.snap.Why it matters
The column looks like coverage of date rendering and is not. A real regression in how
Tablerenders a formatted cell would leaveInvalid Dateexactly where it is and the snapshots would stay green — the same failure shape as the orphaned spec behind #83, one level down: the spec runs, the assertion is live, and it asserts nothing anyone wants.How it was found
Split out of #84 while fixing the suite's timezone (#418). That issue claimed this line was a timezone flake source, on the reasoning that
toLocaleStringwithout an explicittimeZonerenders differently per machine. It does not — becauseInvalid DateisInvalid Datein every zone on earth. The claim was wrong, but it pointed at a real defect of a different kind. #84 has been corrected accordingly.Fix
Add a
datefield to the fixture rows (an ISO string, e.g.'2025-01-01T00:30:00Z') and regenerate the two snapshot files. WithTZnow pinned to UTC by #418, the formatted output is stable across machines, so the regenerated snapshot is safe to commit.Worth checking the other columns in the same spec for the same defect while there.
Priority: P3 — no user-facing impact, but it is dead coverage sitting in the most-referenced component spec in the repo.