test(stammbaum): fix #718 tab-order test for tidy-tree layout (#724) #729

marcel · 2026-06-04T17:55:01+02:00

marcel commented

2026-06-04 17:55:01 +02:00

Problem

On main, this test fails:

StammbaumTree keyboard tab order (#718) > renders node tab stops in reading order, not backend array order
- Expected: ["Eugenie", "Walter", "Clara", "Hans"]
+ Received: ["Walter", "Eugenie", "Clara", "Hans"]

Root cause — a semantic merge conflict between #718 and #724

Neither PR was wrong on its own; they only conflict once both are on main.

#718 added a keyboard-tab-order test that hardcoded the visual order ['Eugenie', 'Walter', 'Clara', 'Hans'], with a comment stating "buildLayout sorts each generation alphabetically".
#724 then replaced buildLayout with the tidy-tree layout, which orders a couple's run by structural ownership (earliest birth year, then a deterministic id tie-break) rather than alphabetically. With no birth years in the fixture, Walter (id …a1) becomes the run primary and Eugenie renders to his right → actual order ['Walter', 'Eugenie', 'Clara', 'Hans'].

Both branches were green independently, so neither CI gate caught it; the stale assertion only surfaced once they landed together.

The companion self-validating test in the same block (DOM order == nodes sorted by y, then x) kept passing — it already guards the real property — so only the hardcoded assertion needed updating.

Fix (test-only)

Correct the expected reading order to ['Walter', 'Eugenie', 'Clara', 'Hans'].
Refresh the now-wrong "sorts each generation alphabetically" comment to describe the tidy-tree structural ordering.

The production layout / tab-order code is correct — tab order still follows the visual reading order, which is the point of #718.

Verification

StammbaumTree.svelte.test.ts — 40/40 pass (both #718 tab-order tests + the rest of the file).

🤖 Generated with Claude Code

## Problem On `main`, this test fails: ``` StammbaumTree keyboard tab order (#718) > renders node tab stops in reading order, not backend array order - Expected: ["Eugenie", "Walter", "Clara", "Hans"] + Received: ["Walter", "Eugenie", "Clara", "Hans"] ``` ## Root cause — a semantic merge conflict between #718 and #724 Neither PR was wrong on its own; they only conflict once both are on `main`. - **#718** added a keyboard-tab-order test that hardcoded the visual order `['Eugenie', 'Walter', 'Clara', 'Hans']`, with a comment stating *"buildLayout sorts each generation alphabetically"*. - **#724** then replaced `buildLayout` with the **tidy-tree layout**, which orders a couple's run by *structural ownership* (earliest birth year, then a deterministic id tie-break) rather than alphabetically. With no birth years in the fixture, Walter (id `…a1`) becomes the run primary and Eugenie renders to his right → actual order `['Walter', 'Eugenie', 'Clara', 'Hans']`. Both branches were green independently, so neither CI gate caught it; the stale assertion only surfaced once they landed together. The companion self-validating test in the same block (DOM order == nodes sorted by `y`, then `x`) kept passing — it already guards the real property — so **only the hardcoded assertion needed updating**. ## Fix (test-only) - Correct the expected reading order to `['Walter', 'Eugenie', 'Clara', 'Hans']`. - Refresh the now-wrong *"sorts each generation alphabetically"* comment to describe the tidy-tree structural ordering. The production layout / tab-order code is correct — tab order still follows the visual reading order, which is the point of #718. ## Verification - `StammbaumTree.svelte.test.ts` — **40/40 pass** (both `#718` tab-order tests + the rest of the file). 🤖 Generated with [Claude Code](https://claude.com/claude-code)

marcel added 1 commit 2026-06-04 18:01:02 +02:00

test(stammbaum): fix #718 tab-order test for tidy-tree layout (#724 )

CI / Unit & Component Tests (pull_request) Successful in 3m17s

Details

CI / OCR Service Tests (pull_request) Successful in 23s

Details

CI / Backend Unit Tests (pull_request) Successful in 3m39s

Details

CI / fail2ban Regex (pull_request) Successful in 44s

Details

CI / Semgrep Security Scan (pull_request) Successful in 23s

Details

CI / Compose Bucket Idempotency (pull_request) Successful in 1m5s

Details

CI / Unit & Component Tests (push) Successful in 3m19s

Details

CI / OCR Service Tests (push) Successful in 23s

Details

CI / fail2ban Regex (push) Has been cancelled

Details

CI / Semgrep Security Scan (push) Has been cancelled

Details

CI / Compose Bucket Idempotency (push) Has been cancelled

Details

CI / Backend Unit Tests (push) Has been cancelled

Details

nightly / deploy-staging (push) Successful in 1m55s

Details

d1ed9c022f

The #718 keyboard-tab-order test hardcoded the visual order
['Eugenie','Walter','Clara','Hans'] on the assumption that buildLayout
sorts each generation alphabetically. #724 replaced that with the
tidy-tree layout, which orders a couple's run by structural ownership
(earliest birth year, then a deterministic id tie-break) — so Walter
(id …a1) now owns the run and Eugenie renders to his right.

Both PRs were green independently; the stale assertion only surfaced
once #718 and #724 landed together on main. Correct the expected reading
order to ['Walter','Eugenie','Clara','Hans'] and refresh the now-wrong
'alphabetical' comment. The companion self-validating test (DOM order ==
sorted by y,x) already guarded the real property, so only the hardcoded
assertion needed updating.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

marcel force-pushed fix/issue-718-tidy-tree-tab-order-stale from ac326f25fa to d1ed9c022f

2026-06-04 18:01:02 +02:00

Compare

marcel merged commit d1ed9c022f into main

2026-06-04 18:16:00 +02:00

marcel deleted branch fix/issue-718-tidy-tree-tab-order-stale

2026-06-04 18:16:01 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marcel/familienarchiv#729