MbUnit 的 [Parallelized] 和 DegreeOfParallelism 究竟是如何工作的？
我以为我理解 MbUnit 的并行测试执行是如何工作的，但我看到的行为与我的预期有很大不同，我怀疑我错过了一些东西！
我有一组希望同时运行的 UI 测试。所有测试都在同一个程序集中，分布在三个不同的命名空间中。所有测试都完全相互独立，因此我希望所有测试都有资格并行执行。
为此，我将以下内容放入 AssemblyInfo.cs 中：
[assembly: DegreeOfParallelism(8)]
[assembly: Parallelizable(TestScope.All)]
我的理解是，程序集属性的这种组合应导致所有测试都被视为 [Parallelizable]，并且测试运行程序应使用执行期间有8个线程。我的各个测试都标有 [Test] 属性，没有其他任何内容。它们都不是数据驱动的。
然而，我实际看到最多使用了 5-6 个线程，这意味着我的测试运行花费的时间比应有的时间要长。
我错过了什么吗？我是否需要做其他事情来确保运行程序正在使用我的所有 8 个线程？
注意无论我使用哪个跑步者，行为都是相同的。 GUI、命令行和 TD.Net 运行程序的行为都与上述相同，这再次让我觉得我错过了一些东西。
编辑：正如评论中所指出的，我正在运行 MbUnit v3.1（更新 2 版本 397）。 文档 建议程序集级别 [parallelizable] 属性为可用，但它似乎也引用了框架的 v3.2，尽管该框架尚未可用。
编辑2：为了进一步澄清，我的程序集的结构如下：
assembly
- namespace
- fixture
- tests (each carrying only the [Test] attribute)
- fixture
- tests (each carrying only the [Test] attribute)
- namespace
- fixture
- tests (each carrying only the [Test] attribute)
- fixture
- tests (each carrying only the [Test] attribute)
- namespace
- fixture
- tests (each carrying only the [Test] attribute)
- fixture
- tests (each carrying only the [Test] attribute)
编辑3：好的，我现在注意到，如果我只在某个时间运行一个装置时间，同时运行的最大测试数量始终为 8。一旦我选择多个装置，它就会下降到 5 或 6。如果我将两个装置的内容（目前每个装置包含 12 个测试）并将它们放入同一个固定装置（该固定装置中总共有 24 个测试）该固定装置也将始终同时运行 8 个测试。
这似乎表明这不是单独测试中的问题，而是程序集级属性如何渗透到固定装置中的问题，或者测试运行程序如何使用这些属性的问题。
此外，我还观察到（当运行两个固定装置时），一旦两个固定装置之一全部执行完毕，运行程序就会开始同时执行更多的测试，而后又回到只运行一个固定装置。现在对我来说，当第二个固定装置中还剩下 7 个测试需要运行时，第一个固定装置就完成了执行。一旦发生这种情况，同时运行的测试数量就会从之前的 5 或 6 个跃升至可用的最大可用数量 7 个。
I thought I understood how MbUnit's parallel test execution worked, but the behaviour I'm seeing differs sufficiently much from my expectation that I suspect I'm missing something!
I have a set of UI tests that I wish to run concurrently. All of the tests are in the same assembly, split across three different namespaces. All of the tests are completely independent of one another, so I'd like all of them to be eligible for parallel execution.
To that end, I put the following in the AssemblyInfo.cs:
[assembly: DegreeOfParallelism(8)]
[assembly: Parallelizable(TestScope.All)]
My understanding was that this combination of assembly attributes should cause all of the tests to be considered [Parallelizable], and that the test runner should use 8 threads during execution. My individual tests are marked with the [Test] attribute, and nothing else. None of them are data-driven.
However, what I actually see is at most 5-6 threads being used, meaning that my test runs are taking longer than they should be.
Am I missing something? Do I need to do anything else to ensure that all of my 8 threads are being used by the runner?
N.B. The behaviour is the same irrespective of which runner I use. The GUI, command line and TD.Net runners all behave the same as described above, again leading me to think I've missed something.
EDIT: As pointed out in the comments, I'm running v3.1 of MbUnit (update 2 build 397). The documentation suggests that the assembly level [parallelizable] attribute is available, but it does also seem to reference v3.2 of the framework despite that not yet being available.
EDIT 2: To further clarify, the structure of my assembly is as follows:
assembly
- namespace
- fixture
- tests (each carrying only the [Test] attribute)
- fixture
- tests (each carrying only the [Test] attribute)
- namespace
- fixture
- tests (each carrying only the [Test] attribute)
- fixture
- tests (each carrying only the [Test] attribute)
- namespace
- fixture
- tests (each carrying only the [Test] attribute)
- fixture
- tests (each carrying only the [Test] attribute)
EDIT 3: OK, I've now noticed that if I only ever run one fixture at a time, the maximum number of tests running concurrently is always 8. As soon as I select multiple fixtures, it drops to either 5 or 6. If I take the contents of two fixtures (currently they contain 12 tests each) and drop them into the same fixture (for a total of 24 tests in that one fixture) that fixture will also always run 8 tests concurrently.
This seems to show that it isn't an issue in the individual tests, but rather in how the assembly level attributes percolate down to the fixture, or how the test runner consumes those attributes.
Additionally, I also observed (when running two fixtures) that once one of the two fixtures had been executed in its entirety, the runner starts to execute more tests concurrently when its back down to running only one fixture. For me right now, the first fixture gets done executing when there are 7 tests left to run in the second fixture. As soon as that happens, the number of tests running concurrently jumps up from the previous 5 or 6 to the maximum available of 7.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据发行说明 Gallio v3.0.6：
我不知道是否有帮助。也许杰夫可以提供更多细节，因为他已经实现了该功能。
According to the release note of Gallio v3.0.6:
I don't know if it helps. Maybe Jeff could give more details as he had implemented that feature.
遇到同样的问题，我
最终，由于装配级对夹具并行限制的限制，唯一的方法是使用夹具级属性并使夹具测试并行运行。
我建议创建更少的夹具并为每个夹具创建更多测试来解决这个问题。也许您总是可以为每个装配夹具启动多个运行程序。
耻辱就是这样。
Ran into same problem, my findings
Ultimately due to the assembly level constraint on fixture parallel limits, the only way is to use fixture level attributes and have fixtures tests run in parallel.
I would suggest creating less fixture and more tests per fixture to get around this issue. You could always launch multiple runners per assembly fixture perhaps.
Shame this is the case.
覆盖对于一次运行超过 5 个测试不起作用。
我们 Sauce 实验室有 25 个系统，可一次执行 25 个脚本，我们将并行度改为 20，一次仅执行 5 个脚本。
[程序集：DegreeOfParallelism(20)] - 不适用于 Mbunit
Override does not work for more than 5 test to run at a time.
We have 25 systems on Sauce labs available to execute 25 scripts at a time, we over ride the DegreeOfParallelism to 20 only 5 executes at a time.
[assembly: DegreeOfParallelism(20)] - Do not Work for Mbunit