北京
你有多少次盯着测试运行，看着它慢吞吞地消耗真实时间，心里只想让它快一点？一个指数退避的重试测试，老老实实等着系统时钟走完1秒、2秒、4秒——这7秒钟，什么都没干，却每一轮都硬扛了下来。测试是正确通过了，但每次跑，心都在滴血。
被测的就是一个标准的瞬时故障重试助手。规则简单：连续三次超时失败后成功，中间各插入1s、2s、4s的等待。老老实实对着真实时钟写测试，长这样：
var retry = new TransientRetry(TimeProvider.System, maxAttempts: 4, baseDelay: TimeSpan.FromSeconds(1));var calls = 0;var result = await retry.ExecuteAsync(() =>++calls < 4 ? throw new TimeoutException("flaky dependency"): Task.FromResult("ok"));Assert.Equal(4, retry.Attempts);Assert.True(sw.Elapsed >= TimeSpan.FromSeconds(7));
一遍，七秒。每次运行，永远七秒。测试本身没错，甚至准确得让人讨厌。再算上失败终止路径的测试、抖动测试、取消令牌测试……一个不起眼的重试工具类，就能悄悄在 CI 流水线里吃掉半分钟。这就是“睡眠税”，多数测试套件里，默默交着。
从 .NET 8 开始，工具箱里多了一把正式的时钟抽象：TimeProvider。重试助手唯一要改的地方，就是接受一个 TimeProvider 并传给 Task.Delay。生产代码喂进去 TimeProvider.System，测试代码用 FakeTimeProvider 接手，直接用手拨动时间——fake.Advance(TimeSpan.FromSeconds(1))——一秒虚拟流逝，零秒真实等待。同样的重试逻辑，任务在每次 Advance 后仍然老老实实挂在后退上，直到第四次尝试成功，瞬间返回结果。整整七虚拟秒，真实耗时为 0。用控制台应用单独跑，完美通过，一切都像教科书一样优雅。
然后，把同一段代码贴进 xUnit 项目，敲下 dotnet test。预期的秒级结果没有出现，控制台静悄悄，一直静到挂起检测器抬手一枪——进程直接毙了。测试不但没有变快，干脆永远没醒过来。
一模一样的方法调用，一模一样的 FakeTimeProvider.Advance，在控制台里跑得像风，进了 xUnit 就死在那，没有任何异常，没有任何输出。那个本应“零秒通过”的测试，连“失败”两个字都来不及写出来，就直接从屏幕上彻底蒸发，只剩下一个被操作系统强行杀掉的进程。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
