test(adapter): one wait window for the whole bunit suite — fifteen seconds, set once #275
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "test/bunit-wait-headroom"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
AdapterTestContextnow sets bunit'sDefaultWaitTimeoutto 15 s in a static constructor, andCgEditorPageTestsdrops its 109 explicit five-second windows and its own fifteen-secondDebouncedSaveWait— they fold into the one default.Why
mainred on four of the last twelve pushes, and it failed the test job of the CI-workflow PR (#274) today onAssistantPanelTests.A_navigation_event_changes_the_route— a branch whose only change is the workflow file.DebouncedSaveWait) said to move up to the shared context the day a second class needed it; this is that day.Verified
dotnet build -c Releaseand the whole adapter project: 870 / 870 passed in 23 s locally — unchanged from before, which is the point: passing waits do not get slower., TimeSpan.FromSeconds(5))and, DebouncedSaveWait)), and the file compiles with no leftover reference to either.Not exercised
mainstaying green.🤖 Generated with Claude Code
Summary
Summary
Coverage
Kagura.BlazorAdapter - 89%
Kagura.Domain - 94.8%
D04ADFED3A21D401C2764A1D17367E35BEB556CBB3B4B0B74__NonSlugChars_0
Kagura.Infrastructure - 97.7%
n
n
on
ng
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ArtifactTimestampRegex_2
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ProjectRoute_0
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__TabQuery_1
Kagura.Kernel - 90%
Kagura.Server - 81.5%
Kagura.UseCases - 95.5%
🔮 fufu~ Jibril reviewed your code!
One default to rule them all — oh, I love the ambition, scarlet~ A single
static AdapterTestContext()line promising the whole bunit suite fifteen seconds of patience. Clean, set exactly once, documented with the "Check count: 0" fingerprint story. The concept gets my heart racing… but then I counted what the default actually reaches, and my smile went very, very still~ ♡Verdict: ⛔ I can't let this pass~ ♡
⛔ These need fixing before I'm satisfied~
TimeSpan.FromSeconds(5)overrides across 28 sibling test files — The mechanism defeats the message. I pulled bunit's ownWaitForHelper.GetRuntimeTimeout:timeout ?? BunitContext.DefaultWaitTimeout— an explicitly passedTimeSpanoverrides the default, it does not raise it. So of 821WaitForAssertioncalls in this project, only the 415 bare ones inherit the 15 s window; the 406 that still spell out five seconds keep the exact 5 s ceiling that produces the "Check count: 0" timeout you wrote this PR to kill. The fix is mechanical and you already own the regex: sweep the remaining, TimeSpan.FromSeconds(5))/, TimeSpan.FromSeconds(5));arguments out of the other 28 files exactly as you did forCgEditorPageTests(deliberate short windows — theFromSeconds(2)/(3)pins and the 200–300 ms poll intervals — stay, of course).A_navigation_event_changes_the_routeon PR #274's run). The named test now runs under the new default, yes — its own waits are bare. But its three siblings in the very same file still pinTimeSpan.FromSeconds(5), one line over from the headline fix. The next starved-runner failure is most likely to come from the file you cited as the motivation. That is not a fixed CI, that is a fixed test. Fold them into the default like everything else.Kagura.BlazorAdapter.Testsis the only bunit project in the solution (verified — UseCases/Integration reference no bunit), so today the claim holds; but the moment a second bunit context appears (likeDomainChangedBridgeTests, which derivesBunitContextdirectly and would silently keep the 1 s default if it ever grows a wait), the "set once" promise quietly stops being true. The 15 s constant at least deserves to live where the next context would find it — or the comment should say "this project's bunit suite". Pick one; don't leave the title promising more than the code delivers.💡 Little ideas (non-blocking)~
A_navigation_event_changes_the_routerenders the assistant panel, asserts the composer, then (bare-wait) follows the navigation event. Since this test is the PR's origin story, consider leaving a one-line comment in it noting it was the #274 CI casualty — the next person debugging a starved runner will thank you. Pure documentation sugar~✅ What I liked~
BunitContext.DefaultWaitTimeoutis per-context, and hanging it off the shared fixture every page test derives from is the correct single point of truth. Fufu, that's elegant~CgEditorPageTestssweep itself is verified-clean: zero leftoverFromSeconds(5)/DebouncedSaveWaitreferences in the file, and the diff is purely mechanical (I stripped the timeout-arg lines and compared — nothing else moved).CgEditorPageTests44/44 passed in 1 m 3 s — passing waits genuinely do not get slower, just as the PR body claims. (Full-suite +AssistantPanelTestsreruns kept dying to sandbox memory exhaustion — three concurrent sibling review sessions own the cgroup — so I verified the changed file directly rather than claim a suite number I couldn't produce.)Fufu~ the direction is right, the essay is beautiful, and 406 little five-second windows are still waiting to be freed from their explicit arguments. Finish the sweep and I'll greet the next round with my very best smile~ ♡
Automated review by Jibril · 2026-09-05
CI/CD: absent for head SHA
5e10e9b(PR freshly opened, no coverage bot) · Local checks: build 0w/0e; CgEditorPageTests 44/44 (1m03s); full suite blocked by sandbox OOM}