真正的单元测试可以始终并行运行吗？答案

【问题标题】：Can true unit tests always be run in parallel?真正的单元测试可以始终并行运行吗？
【发布时间】：2015-12-04 09:18:45
【问题描述】：

背景：

我正在编写很多 go 代码，使用 go test 工具和提供的 "testing" 包进行测试。我所做的大部分测试都是单元测试，属于 TDD 规则。这些被测“单元”永远不允许依赖于有状态的外部性，如持久存储、网络跃点等，但通常在“构造器/构建器”函数中接收这些外部性的虚假内存实现（是的，我知道它们不是传统意义上的构造函数）。

问题：

go test 工具总是以相同的确定性顺序运行测试函数，这让我很困扰。在某些情况下，这允许竞争条件隐藏在代码中。找到这些错误的一种方法是设置-race 标志。另一个可能是始终并行运行单元测试......

问题：

是否存在曾经孤立单元测试不能或不应该总是并行运行的情况（使用-parallel标志）？

【问题讨论】：

单元测试应该是确定性的，这就是为什么-parallel 是您可以在明确需要时使用的选项。如果一个单元测试将失败，它应该每次都失败。在并行或以任何顺序运行部分代码时，您绝对应该测试不正确的行为，就像您测试任何其他错误情况一样，但这不属于大多数人对单元测试的定义。
我同意，我希望我不会忽略任何明显的冲突案例。
明显的冲突案例到底是什么？您要么编写可以并行运行的单元测试，要么不编写。如果您想并行运行测试完全取决于您，但大多数人不希望将其作为默认设置，因为单元测试每次都应该执行完全相同。

标签： unit-testing go tdd

【解决方案1】：

parallel 标志实际上是一种测试测试本身的方法（除了加快测试速度）。当以不确定的顺序运行时，发现测试随机中断表明错误的测试与错误的代码一样频繁。

Ruby 的测试运行器做了一些有趣的事情（Rspec 和 Minitest）——它们在每次运行时随机化测试顺序，但打印一个用于运行的整数种子。这允许重现错误，同时仍确保没有测试依赖于隐式排序。我不知道有任何 Go 测试运行程序这样做，但这会非常有用。

【讨论】：

Ginkgo 允许随机化。 GoConvey 几乎也有这个功能。
随机执行仍然不同于并行执行。