perf(engine): collapse async state machines on hook cache-hit / empty-hook path (#5713)

[thomhurst]

Closes #5713

Summary

• Per-test hot path previously materialized ~4 async state machines even when the per-class hook cache was populated and the hook lists were empty. HookDelegateBuilder.Collect*(Test|Class|Assembly)HooksAsync were marked async and still boxed a state machine on cache hit; HookExecutor.Execute(Before|After)TestHooksAsync awaited every hook accessor even when both lists were empty.
• Split each Collect*HooksAsync into a sync ValueTask-returning wrapper (cache hit returns synchronously) plus a private async builder helper used only on cache miss.
• Added sync TryGetCached(Before|After)TestHooks + GetCached(Before|After)EveryTestHooks accessors to IHookDelegateBuilder. HookExecutor.Execute(Before|After)TestHooksAsync is now a non-async wrapper that returns a completed ValueTask when both lists are known-empty, and delegates to a private core helper only when hooks exist.
• Hook ordering semantics preserved: beforeEvery -> before for Before, after -> afterEvery for After.

Expected impact

• ~1% CPU per test on the steady-state path.
• 4 fewer async state machines allocated per test.

Test plan

• dotnet build TUnit.slnx -c Release (0 errors, 237 warnings — all pre-existing)
• TUnit.Core.SourceGenerator.Tests snapshot suite (net10.0): 116 passed, 1 pre-existing skip
• TUnit.TestProject -- --treenode-filter "/*/*/HookExecutorTests/*" (net10.0): 5/5 pass
• TUnit.TestProject -- --treenode-filter "/*/*/HookExecutorHookTests_*/*" (net10.0): 4/4 pass
• TUnit.Engine.Tests -- --treenode-filter "/*/*/HookExecutionOrderTests/*" (net10.0): 1/1 pass (ordering invariant holds)
• TUnit.UnitTests (net10.0): 180/180 pass (exercises StubHookDelegateBuilder with the new interface members)

[claude]

Code Review

Overall: Solid, well-scoped performance optimization. No blocking issues.

This PR correctly applies the standard C# "sync fast-path / async slow-path" pattern to eliminate ~4 async state machine allocations per test on the steady-state (no-hooks) path. The approach is idiomatic and follows TUnit's existing ValueTask conventions.

---

What works well

• Correctness on all three paths: The cache-miss path (first test of a given class type), the cache-hit path, and the empty-hooks short-circuit all behave identically to the original semantics. The TryGetCachedBeforeTestHooks / hasCachedBeforeTestHooks guard correctly prevents the empty-list short-circuit from firing on a cold cache, so the full async build path is still taken when needed.
• Consistent pattern across all hook scopes: The same refactor is applied to Class, Assembly, and Session hook builders — not just Test. This is the right call; it eliminates the unnecessary state machine on every cache hit regardless of scope.
• Incidental .ConfigureAwait(false) additions: The new private BuildAndCache* helpers now have .ConfigureAwait(false) that the original async methods were missing. Small but correct improvement.
• Interface changes are appropriately scoped: IHookDelegateBuilder is internal, all implementors are in-repo, and the unit-test stub (StubHookDelegateBuilder) is correctly updated to implement the four new members.

---

One observation worth noting (not a blocker)

_beforeEveryTestHooks / _afterEveryTestHooks visibility on the read path

GetCachedBeforeEveryTestHooks() reads _beforeEveryTestHooks without a memory barrier and returns _beforeEveryTestHooks ?? []. This is safe today because InitializeAsync() is fully awaited before any test executes — so the write always happens-before the reads. But if that startup ordering were ever relaxed, a test thread could observe null and silently run with an empty hook list instead of the real one.

This is an existing pattern in the codebase and is fine here, but consider adding a brief comment or an ObjectDisposedException/assertion guard if this ever moves to a lazier initialization model.

---

Impact

For a test suite with thousands of tests and no hooks (the most common case), this removes 4 heap allocations per test. On 10 000 tests that's 40 000 fewer short-lived objects on the heap per run — a meaningful reduction in GC pressure with no behavior change. The "~1% CPU" estimate is plausible and likely conservative on allocation-heavy workloads.

Approved. Clean implementation of an established C# perf pattern, correct across all edge cases.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 22 complexity

Metric	Results
Complexity	22

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[thomhurst]

macOS CI failure diagnosis

The macOS failure is unrelated to this PR's changes.

Failing test: GenerateMock_Attribute_With_Concrete_Class in TUnit.Mocks.SourceGenerator.Tests — a snapshot-comparison test for the mock source generator output. The PR touches only HookExecutor, HookDelegateBuilder, IHookDelegateBuilder, and a unit test in TUnit.UnitTests — none of which are reachable from that source-generator snapshot test.

Evidence this is pre-existing: The prior macOS run on main (run 24864304955, commit 35e2ef3) had multiple TUnit.Mocks.SourceGenerator.Tests snapshot mismatches on both macOS and Ubuntu, before this PR was opened. Looks like a platform-specific snapshot flake (likely line-ending / analyzer version / arm64-vs-x64 generator output differences) that is already affecting main.

Action: Once the current workflow run finishes (Windows + Ubuntu jobs are still in progress in the same run, so it can't be re-run partial yet) I'll re-run the failed macOS job. Alternatively any new push will trigger a fresh run.