我有单元测试。如果其中一个失败，我的构建就会失败。
我想将相同的原则应用于性能。我有一系列通过库的几个热路径的微基准。根据经验，这些领域的放缓对图书馆的整体性能产生了不成比例的影响。
如果有某种方法可以让某个“性能构建”概念在过于显着的性能回归的情况下失败，那就太好了。
我曾考虑过不得超过的硬编码阈值。就像是：
Assert.IsTrue(hotPathTestResult.TotalTime <= threshold)
但是将其与绝对值挂钩取决于硬件和环境，因此很脆弱。
有没有人实施过这样的事情？微软为 Kestrel 做了什么？
我不会通过单元测试来做到这一点——这是错误的地方。在构建/测试脚本中执行此操作。您获得了更大的灵活性，并且可以做更多可能需要的事情。
粗略的大纲是：
在 6. 如果存在回归，您可以让构建失败并使用非零退出代码。
BenchmarkDotNet 可以将结果导出为 JSON 等，因此您可以利用它。
关键是如何确定是否发生回归。特别是在 CI 构建（使用容器等）上，不同的基准测试运行可能会有不同的硬件，因此结果不是 1:1 可比的，您必须考虑到这一点。
就我个人而言，我不会让脚本在可能出现回归的情况下失败，但它会发送有关此的信息，因此我可以手动检查它是真正的回归还是只是不同硬件的原因。
如果当前结果比最后 5 个结果的中位数更差，则简单地检测到回归。当然，这是一种粗略的方法，但是一种有效的方法，您可以根据需要对其进行调整。