Skip to content

Residual legend assertions and layout measurement from #1965 #1980

Description

@steilerDev

[product-owner]

As a maintainer of the bank report pipeline, I want the residual legend assertions from #1965 written at the surfaces its acceptance criteria named, so that the legend cannot silently disappear from a document going to a bank the next time the report table is reworked.

Parent Epic: none — part of the parent-less Bank Report Wizard cluster (#1876-#1879, #1898-#1901, #1923, #1959, #1965).
Priority: Should Have

Context

#1965 (PR #1979) reinstated the two legend sentences and was approved. Four assertion/measurement gaps were accepted as non-blocking at review time because each is covered transitively (see the reasoning per item below) — none of them concealed a live defect. They are collected here so the coverage does not stay half-written.

Background on why this matters more than a normal coverage item: #1959 emptied content.footnotes and the only guard in the suite was an array-level expect(content.footnotes).toEqual([]), which was simply updated to match the removal. The regression reached a released PDF. PR #1979 closed that channel for both sentences in both locales on the rendered PDF surface, and closed the dedup count on the rendered preview DOM. What remains is the mirror image of each.

Acceptance Criteria

  • 1 AC 4.1 of Report legend: reinstate the explanatory sentences for partial and deposit-reduced amounts #1965 is satisfied by a measured assertion: a real render (client/src/lib/reportPdf/realRender.test.ts) with both legend sentences present, at the report's configured page size, asserting every legend text node's laid-out box falls inside the printable area and that no glyph is clipped. Use the machinery already in the file — PRINTABLE_WIDTH_PT and the laid-out-node y-position pattern. A bounded version is acceptable: both sentences present, every legend text node within the printable box, page count sane. Reasoning, not measurement, is what is missing today; the risk itself is low (two short, space-wrappable sentences, longest unbreakable token Abschlagszahlungen.).
  • 2 AC 1.5's rendered-PDF-text occurrence count is asserted directly: given N > 1 rows carrying the same flag, the sentence appears exactly once in the collected rendered PDF strings — a count, not allStrings.some(...). Today this holds transitively (array length is pinned in buildReportContent.test.ts and realRender.test.ts, and overviewPdf.ts's verbatim append is pinned by its own case), but the count itself is unasserted on that surface.
  • 3 AC 1.4's rendered-PDF-text negative is asserted on the rendered surface, not only on the array: given a report where neither flag occurs on any included row, neither sentence appears in the collected rendered PDF strings. The preview half is already covered in a real browser by Scenario 17 (footnotesBlock count 0).
  • 4 The deduplication case is covered for depositReduced, not split only — N > 1 deposit-reduced rows yield exactly one legend entry (buildReportContent.test.ts currently has the two-split-invoices case only).
  • 5 The deposit-reduced legend sentence has rendered-preview coverage. No E2E scenario currently produces an isDepositReduced row, so the sentence the story called load-bearing (separately, the audit-relevant word) is asserted in the rendered PDF tree and in a jsdom fixture, but never in a real browser preview. Either add a deposit-reduced fixture to e2e/tests/budget/reportWizardEditableContent.spec.ts asserting the legend item and its text, or extend Scenario 18's fixture to carry both flags and assert two legend items in the documented order (split first).

Notes

Metadata

Metadata

Assignees

No one assigned

    Projects

    Status
    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions