将 t.Parallel() 放在我的测试顶部有什么实际好处？

Question

gotesting包定义了一个 Parallel() 函数：

并行表示此测试将与（且仅与）其他并行测试并行运行。

然而，当我搜索为标准库编写的测试时，我发现这个函数只有少数用途。

我的测试非常快，并且通常不依赖于改变共享状态，所以我一直在添加它，认为它会导致加速。但它没有在标准库中使用的事实让我停顿了一下。添加t.Parallel()到您的测试中有什么实际好处？

Answer 1

该线程（在其中t.Parallel构思和讨论）表明t.Parallel()仅用于慢速测试；平均测试速度如此之快，以至于从并行执行中获得的任何收益都可以忽略不计。以下是一些引述（仅来自 Russ，但没有太多反对意见）：拉斯·考克斯[链接]：关于什么是正确的默认值存在一些问题。我们的大多数测试运行得如此之快，以至于没有必要对其进行并行化。我认为这可能是正确的模型，这表明并行化是例外，而不是规则。作为一个例外，这可以容纳一个 t.Parallel() 方法，测试可以调用该方法来声明可以与其他测试并行运行。Russ Cox 再次 [链接]：非并行测试应该很快。他们无关紧要。如果两个测试很慢，那么如果它困扰你，你可以 t.Parallel 它们。如果一项测试很慢，那么，一项测试很慢。

Answer 2

这似乎首先在 golang-dev 组中提出。最初的请求指出：“我想添加一个选项来与 gotest 并行运行测试。我的动机来自运行 selenium 测试，其中每个测试几乎彼此独立，但它们需要时间。”该线程包含对实际好处的讨论。它实际上只是为了允许您同时运行不相关的、长时间运行的测试。它并没有真正在标准库中使用，因为几乎所有功能都需要尽可能快（一些加密异常等）有进一步的讨论在这里和承诺是这里