如何为 Azure DevOps 多代理测试并行化将多测试 dll 拆分为每个测试类的单独 dll

Question

Azure DevOps 能够跨 multiple agents in parallel 运行 Visual Studio 测试。我想利用这一点，但是当我更新构建管道以使用 Based on past running time of tests 策略跨多个代理运行时，每个代理都分配了至少一个 整个 测试程序集（即 TestSuite1.dll 、TestSuite2.dll 等）。这意味着我们每个独立的 MSTest TestClass'es 都有大量的并行化机会，因为我们的测试被设计为具有类级别的执行范围。

我们的 Azure DevOps 管道成功实现了每个基础测试程序集跨代理的并行化，但显然我们更喜欢在我们的测试程序集中对每个不同的测试进行切片，所以 实现跨代理拆分每个派生 TestClass 的最佳策略是什么（最好不重构我们的整个测试代码）？

注意事项：

我已经生成 xml 以“成功”将一个 TestClass 构建到它自己的 .dll 中，然后在 Visual Studio Test 任务中仅引用该 .dll，但是一旦实际发生了引用\重定向问题，就会出现大量程序集类开始执行超过[AssemblyInitialize] 代码。由于我拥有整个解决方案的构建输出，因此我可以访问为整个测试程序集运行的 csc 命令，但同样无法对其进行测试，我假设只是引用其中的配置参数对未来的变化很脆弱。另外，我认为除了Select tests using Test Assemblies 之外的任何东西执行Visual Studio Test 任务都不会受益于Based on past running time of tests 切片策略。

Answer 1

动态生成测试程序集似乎很疯狂，但您可以将所有基本管道逻辑移动到“测试框架”程序集中，然后以编程方式为每个 TestClass 生成测试程序集：

csc TestClassName.cs -reference:TestFramework.dll

或者...

与其尝试以编程方式重新组织测试，不如手动将测试拆分为不同的逻辑分组更有意义。理想情况下，您会在命名空间或其他重要边界处拆分它们。理论上，您还可以将它们重新组织到任意存储桶（快/慢，或 0、1、2、3）中，并将持续时间相等的测试类移动到适当的存储桶中，以实现所需的时序平衡。 Eg (Namespace.0.Tests.dll, Namespace.1.Tests.dll, Namespace.2.Tests.dll) 诚然，单元测试的可发现性会受到影响。

或者....

Jez Humble Continous Delivery 的建议适用于此处：“如果疼，就多做”。你所描述的听起来很痛苦，你应该深入研究那种痛苦，而不是试图用更多的痛苦来解决它（比如跺脚以减轻肘部撞击）。

Azure DevOps 团队经历了一场类似的变革：他们使用 TestHarness 进行了许多测试，但他们想放弃这些测试。他们标记了他们所有的遗留测试，并制定了一项长期战略，以在设定的日期前摆脱该模型。您的方法可能类似：

1. 创建测试代表理想策略的程序集。这些测试应该能够在彼此隔离的情况下并行运行，并且能够利用strategies #1 and #2 listed in the multi-agent article you shared

2. 尽可能将任何东西移至上述程序集。对于其他一切，请计划在以后移动它们。

3. 使用 KPI 报告进度：构建长度、使用旧框架的测试数。然后重复 1 和 2，直到您使用更有效的模型解决了您的痛苦。