Stabilize immediate WaitsFor assertion test

[thomhurst]

Summary

• replace the wall-clock threshold in the immediate WaitsFor test with an exact attempt-count assertion
• verify successful assertions complete on the first polling attempt without relying on runner speed

Root cause

Ubuntu CI exceeded the test's 100 ms threshold by 0.6408 ms under load even though the assertion passed immediately. Elapsed time was an indirect and environment-sensitive proxy for retry behavior.

Impact

The test now checks the intended behavior deterministically and no longer flakes on slow CI runners.

Validation

• dotnet test tests/TUnit.Assertions.Tests/TUnit.Assertions.Tests.csproj --configuration Release --framework net10.0 --no-build --treenode-filter "/*/*/WaitsForAssertionTests/*" — 27 passed
• focused immediate-success test — passed once with build plus 10 repeated no-build runs

Originating failure: https://github.com/thomhurst/TUnit/actions/runs/31318658536/job/93257973205

[coderabbitai]

Warning

Review limit reached

@thomhurst, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 12 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ea96eda3-049f-4501-9ba3-a1f5fcc8b44b

📥 Commits

Reviewing files that changed from the base of the PR and between a3da74c and 93c501d.

📒 Files selected for processing (1)

• tests/TUnit.Assertions.Tests/WaitsForAssertionTests.cs

---

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

This PR makes the immediate WaitsFor test deterministic by checking polling attempts instead of elapsed wall-clock time.

• Replaces the 100 ms timing threshold with a local attempt counter.
• Verifies that an immediately successful assertion completes on its first polling attempt.

Confidence Score: 5/5

The PR appears safe to merge with no actionable issues identified.

The revised test directly verifies first-attempt success, and the polling implementation invokes the assertion factory once per attempt and exits immediately when that assertion passes.

Important Files Changed

Filename	Overview
tests/TUnit.Assertions.Tests/WaitsForAssertionTests.cs	Replaces a flaky elapsed-time assertion with an exact invocation-count check that matches WaitsFor polling semantics.

_{Reviews (1): Last reviewed commit: "test: remove WaitsFor timing flake" | Re-trigger Greptile}

[claude]

Code review

Verified the change against the actual WaitsFor implementation (src/TUnit.Assertions/Conditions/WaitsForAssertion.cs): _assertionBuilder is invoked exactly once per polling attempt, and the loop returns AssertionResult.Passed immediately on success — so attemptCount == 1 is a correct, deterministic assertion for the "passes immediately" case. This is a solid fix: replacing a wall-clock threshold with a direct behavioral assertion (attempt count) removes the CI-load sensitivity that caused the original flake, and does so without weakening what the test actually verifies.

No bugs found, and no CLAUDE.md violations — this is a test-only change with no core engine metadata, source-gen, or public API impact, so the dual-mode/snapshot/AOT rules don't apply here.

One optional, non-blocking observation for future consistency: several other tests in this same file rely on the same environment-sensitive pattern this PR eliminated — e.g. WaitsFor_With_Custom_Polling_Interval asserts stopwatch.Elapsed > 40ms, and the cancellation-propagation tests assert elapsed time < 1s / < 500ms. These carry the same class of risk (failing under CI load despite correct behavior) that caused this flake. Not required for this PR, but worth a follow-up if those ever start flaking too — the attempt-count/counter approach used here would generalize well to them.