From 91dac14e99bad5db05a7b7f57872b76503dfd025 Mon Sep 17 00:00:00 2001
From: Tom Longhurst <30480171+thomhurst@users.noreply.github.com>
Date: Mon, 11 May 2026 11:42:45 +0100
Subject: [PATCH] test(assertions): replace flaky upper-bound wall-clock with
 timeout-fired lower-bound

WaitsFor_Fails_When_Timeout_Expires asserted the entire test method
completed in <1s while configuring a 100ms timeout. On a slow Windows
CI worker, exception construction + assertion-machinery cost pushed the
total to 2.118s, failing the test even though the 100ms timeout itself
was respected (run 24793788489).

Replace the upper-bound check with the lower-bound invariant the test
should actually be guarding: the timeout fired no earlier than the
configured 100ms.
---
 TUnit.Assertions.Tests/WaitsForAssertionTests.cs | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/TUnit.Assertions.Tests/WaitsForAssertionTests.cs b/TUnit.Assertions.Tests/WaitsForAssertionTests.cs
index e84417729c..4c0c3e51f2 100644
--- a/TUnit.Assertions.Tests/WaitsForAssertionTests.cs
+++ b/TUnit.Assertions.Tests/WaitsForAssertionTests.cs
@@ -56,8 +56,10 @@ public async Task WaitsFor_Fails_When_Timeout_Expires()
 
         stopwatch.Stop();
 
-        // Verify timeout was respected (should be close to 100ms, not significantly longer)
-        await Assert.That(stopwatch.Elapsed).IsLessThan(TimeSpan.FromSeconds(1));
+        // Lower bound proves the timeout actually fired at the right moment. An upper bound
+        // here is a flake magnet — slow CI workers can spend >1s in exception construction
+        // and assertion-machinery cost after the timeout fires correctly.
+        await Assert.That(stopwatch.Elapsed).IsGreaterThanOrEqualTo(TimeSpan.FromMilliseconds(100));
 
         // Verify error message contains useful information
         await Assert.That(exception.Message).Contains("assertion did not pass within 100ms");