test: the engine helper takes its defaults from the engine #88
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "worktree-test-engine-helper-mirrors-defaults"
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?
Picks up the late 💡 from #87:
RunEngineTests.Engine(int concurrency = 3, …)kept its own3after production moved to5, so the helper silently stopped mirroringnew RunEngineOptions().Taking the suggested one-character bump would have fixed today's divergence and rebuilt the mechanism for the next one — a second copy of the production number, in a file nobody thinks about when tuning the engine. So the unset arguments now come from
RunEngineOptionsitself:The two cannot disagree again, whatever the numbers become.
Test-only, one file, +6/−2. Every call site is unchanged: the explicit ones (
Engine(concurrency: 2),Engine(maxAttempts: 2)) still pin their own values, and the bareEngine()calls now genuinely run on whatever the app ships. UseCases suite green at 328.🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.7%
Orihon.Domain - 100%
Orihon.Infrastructure - 96.3%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 93.3%
Orihon.UseCases - 97.3%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh my~ ♡ A PR that exists only to fix the very thing I whispered about last time. You came back for my non-blocker, and you didn't just slap a
5over the3— you killed the second copy entirely. The helper now drinks straight from the source. Delicious.Verdict: ✅ Looks good to me~
I verified every load-bearing claim in the PR body, because green CI means nothing if the numbers lie~ ♡
The mechanism is sound.
RunEngineOptionsat this SHA isrecord RunEngineOptions(int ConcurrencyLimit = 5, int MaxAttempts = 3), sonew RunEngineOptions()yields (5, 3) — the shipped defaults. The??plumbing means null falls through to shipped, explicit values pin. The two numbers genuinely cannot disagree again, whatever they become. That's a structural fix, not a cosmetic one.Every call site is accounted for. I traced all 17
Engine(...)calls:Engine()calls previously ran on hardcoded (3, 3); now they run on shipped (5, 3). None of those tests care about the tuning — they exercise retry, resume, partial re-run, feedback — so the concurrency drift from 3→5 is invisible and correct. That's the whole point.Engine(concurrency: 2)at line 259 — the only test that asserts fan-out behavior (peak <= 2over 6 executions) — still pins its own 2. Untouched. The cap test remains a cap test. ✓Engine(maxAttempts: 2)/(maxAttempts: 3)— retry-focused tests, MaxAttempts pinned, ConcurrencyLimit now follows shipped. Correct: they were never about concurrency.No new branches to test. The
??has two arms, but this is a test helper, not production code — and both arms are exercised anyway (null arm by the 12 bare calls, non-null arm by the 5 explicit calls). Nothing hiding in the dark here~ ♪✅ What I liked~
3→5was right there, and instead you asked "why does this number exist in two places at all?" That's the right question. DRY isn't just about saving keystrokes — it's about making drift impossible. fufu~ ♡int→int?) is exactly the right idiom for "caller may omit."nullmeans "I don't care, use shipped" — semantically richer than overloading.Automated review by Jibril · 2026-07-27
CI/CD: absent for head
8aa8cb7(PR just opened, no coverage bot) · Local checks: build 0 warnings/0 errors, UseCases 328/328 pass (matches PR body)