c# - 为什么覆盖 Parallel.foreach 循环的 .NET 单元测试依赖于硬件？

Question

我正在使用 Moq 对一些包含 Parallel.foreach 循环的代码进行单元测试。

Arrange 阶段设置了 4 个要在循环内抛出的异常，然后包装在 AggregateException 中。

这通过了我的 i7 处理器，我检查了代码。

之后，一位同事提示说他没有通过考试。事实证明，Parallel.foreach 在崩溃之前只在他的 Core2duo 上生成了 2 个线程，因此只有 2 个异常被包裹在 AggregateException 中。

问题是如何做才能使单元测试不依赖于处理器架构？一些想法:-

1. 有一个Microsoft article手动添加异常(exception)AggregateException 但我们并不热衷于将此作为循环如果出现问题，应尽早退出。
2. ParallelOptions.MaxDegreeOfParallelism能够对使用的线程数设置上限。但除非这被拒绝到 1(这看起来更像是作弊而不是适当的单元测试)如何单元测试可以知道实际使用了多少线程吗？因此正确设置Arrange 和Assert 阶段？

Answer 1

您不应该测试类似的东西 - 它是实现细节。

事情是 - Parallel.ForEach 将处理元素直到出现异常。当异常发生时，它将停止处理任何新元素(但将完成对当前处理的元素的处理)，然后抛出 AgregateException。

现在 - 你的 i7 CPU 有 4 个核心 + 超线程，这会产生更多的线程来处理，因此你可以获得更多的异常(因为例如当异常发生时可以同时处理 4 个东西)。但是在只有 2 个内核的 Core2Duo 上，只会同时处理 2 个项目(这是因为 TPL 足够聪明，只创建足够的线程来处理，不超过可用内核)。

实际发生了 4 个异常的测试让您一无所知。这取决于机器。您应该改为测试是否至少发生了一个异常——因为那是您所期望的。如果 future 的用户将在旧的单核机器上运行您的代码，他将在 AggregateException 中收到这个异常。

抛出的异常数量是特定于机器的，例如计算时间 - 您不会断言计算了多长时间，因此在这种情况下您不应该断言异常数量。