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