fix(test): correct the sold-filter tally assertion stranded by #188 (#239) #240

2026-08-29T19:19:16-05:00

bermudalamb commented

2026-08-29 19:19:16 -05:00

This is why main has been red since 25 August. One line of test, no production change.

Every SonarQube run has reported 147 passed, 1 failed, and it has been the same test every time:

sold-filter.spec.ts:81 › does not inflate the Filters count
  Expected: "Filters"    Received: "Filters (1)"

The test is stale, not the code


Test last touched	`549a080`, 2026-08-23 (#137)
Tally logic changed	`3242018`, 2026-08-25 (#188)
Did #188 touch this spec?	No

#188 redefined the tally as "the number of chips" and moved the availability preset into the dimension system as a bar dimension — one that still emits a chip for any non-default status, deliberately: without it, ?status=reserved is an empty grid with no Clear filters button and no way out but editing the URL by hand. The test asserted the rule that held before that change, and nothing updated it.

Counting bar chips differently from drawer chips would restore exactly the per-screen special-casing #188 removed, and the drift it fixed was the admin's tally disagreeing with the storefront's. So the assertion moves, not the tally.

Also strengthened while it was open

The replacement asserts the tally comes back down when the default is restored. The original only checked one direction — it would have passed against a count that incremented and never decremented. Not worth leaving a second gap behind the first.

A wart left standing, deliberately

Filters (1) opens a drawer with nothing selected in it, because the filter being counted lives in the bar. That is a cost of #188's design rather than a defect in it. The comment now says so, so the next reader does not have to rediscover it.

Verification

The changed spec in isolation, single worker: 6 passed.

Full suite, serial, against a fresh database: 146 passed, 2 failed. Both failures are password-reset.spec.ts, failing on password authentication failed for user "redefined_local" — the e2e database helper expects the credentials start-local.ps1 creates, and the throwaway container used for this run had different ones. Environment, not code.

All three filter specs passed in that serial run, including this one — so the fix holds at suite level, not just in isolation.

Found alongside — filed as #241

The same suite run in parallel failed three filter specs; two of them pass alone with --workers=1. fullyParallel: true runs specs concurrently against a single shared database, so they interfere depending on scheduling. CI has been lucky with ordering and only ever surfaced this one, which means two of its reported "passes" are luck rather than evidence.

That is the more dangerous of the two problems — it makes any future e2e failure a judgement call rather than a signal — and it is deliberately not fixed here. #241 has the options.

Closes #239

**This is why `main` has been red since 25 August.** One line of test, no production change. Every SonarQube run has reported `147 passed, 1 failed`, and it has been the same test every time: ``` sold-filter.spec.ts:81 › does not inflate the Filters count Expected: "Filters" Received: "Filters (1)" ``` ## The test is stale, not the code | | | | --- | --- | | Test last touched | `549a080`, 2026-08-23 (#137) | | Tally logic changed | `3242018`, 2026-08-25 (#188) | | Did #188 touch this spec? | No | #188 redefined the tally as "the number of chips" and moved the availability preset into the dimension system as a `bar` dimension — one that still emits a chip for any non-default status, deliberately: without it, `?status=reserved` is an empty grid with no Clear filters button and no way out but editing the URL by hand. The test asserted the rule that held before that change, and nothing updated it. Counting bar chips differently from drawer chips would restore exactly the per-screen special-casing #188 removed, and the drift it fixed was the admin's tally disagreeing with the storefront's. So the assertion moves, not the tally. ## Also strengthened while it was open The replacement asserts the tally comes back **down** when the default is restored. The original only checked one direction — it would have passed against a count that incremented and never decremented. Not worth leaving a second gap behind the first. ## A wart left standing, deliberately `Filters (1)` opens a drawer with nothing selected in it, because the filter being counted lives in the bar. That is a cost of #188's design rather than a defect in it. The comment now says so, so the next reader does not have to rediscover it. ## Verification The changed spec in isolation, single worker: **6 passed**. Full suite, serial, against a fresh database: **146 passed, 2 failed**. Both failures are `password-reset.spec.ts`, failing on `password authentication failed for user "redefined_local"` — the e2e database helper expects the credentials `start-local.ps1` creates, and the throwaway container used for this run had different ones. Environment, not code. **All three filter specs passed in that serial run**, including this one — so the fix holds at suite level, not just in isolation. ## Found alongside — filed as #241 The same suite run **in parallel** failed three filter specs; two of them pass alone with `--workers=1`. `fullyParallel: true` runs specs concurrently against a single shared database, so they interfere depending on scheduling. CI has been lucky with ordering and only ever surfaced this one, which means two of its reported "passes" are luck rather than evidence. That is the more dangerous of the two problems — it makes any future e2e failure a judgement call rather than a signal — and it is deliberately **not** fixed here. #241 has the options. Closes #239

bermudalamb added 1 commit 2026-08-29 19:19:18 -05:00

fix(test): correct the sold-filter tally assertion stranded by #188 (#239 )

SonarQube Analysis / sonarqube (pull_request) Successful in 21m4s

Details

Linting / lint (pull_request) Successful in 2m20s

Details

30227fb1e1

main has been red since 2026-08-25. Every SonarQube run reported 147 passed, 1 failed, and it was this test every time — expected "Filters", received "Filters (1)".

The test is stale, not the code. It was last touched on 2026-08-23 in #137; the tally logic changed on 2026-08-25 in #188, which never touched the spec. #188 redefined the tally as the number of chips and moved the availability preset into the dimension system as a bar dimension — one that still emits a chip for any non-default status, deliberately, because without it `?status=reserved` is an empty grid with no Clear filters button and no way out but editing the URL. The test asserted the rule that held before that change.

Counting bar chips differently from drawer chips would restore exactly the per-screen special-casing #188 removed, and the drift it fixed was the admin's tally disagreeing with the storefront's. So the assertion moves, not the tally.

The replacement also checks the tally comes back down when the default is restored. The original only ever asserted one direction, which would pass against a count that incremented and never decremented — worth fixing while the test is open rather than leaving a second gap behind the first.

There is a real wart left standing: `Filters (1)` opens a drawer with nothing selected in it, because the filter it is counting lives in the bar. That is a cost of #188's design rather than a defect in it, and the comment now says so rather than leaving the next reader to rediscover it.

Verified by running the spec in isolation with a single worker: 6 passed.

Closes #239

bermudalamb merged commit 2ba35f8732 into main

2026-08-29 19:22:13 -05:00

bermudalamb deleted branch fix/239-sold-filter-tally

2026-08-29 19:22:17 -05:00

bermudalamb referenced this pull request

2026-08-30 16:20:52 -05:00

test(e2e): skip the admin save happy-path test while #241 stands (#245) #246

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#240