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