将t.Parallel()放在测试顶部的实际好处是什么?

go testing </ code>包定义了一个Parallel()函数:</ p>


并行表示此测试将被执行 </ p>
</ blockquote>

但是,当我搜索为标准库编写的测试时,我发现只有很少的用途 函数。</ p>

我的测试非常快,并且通常不依赖于更改共享状态,因此我一直在添加它,弄清楚它会导致加速。 但是事实上它没有在标准库中使用,这让我停下来。 将 t.Parallel()</ code>添加到测试中有什么实际好处?</ p>
</ div>

展开原文

原文

The go testing package defines a Parallel() function:

Parallel signals that this test is to be run in parallel with (and only with) other parallel tests.

However when I searched the tests written for the standard library, I found only a few uses of this function.

My tests are pretty fast, and generally don't rely on mutating shared state, so I've been adding this, figuring it would lead to a speedup. But the fact it's not used in the standard library gives me pause. What is the practical benefit to adding t.Parallel() to your tests?

2个回答



这似乎最早是在位于golang-dev组上。</ p>

初始请求状态为:</ p>


“我想添加一个选项来与getest并行运行测试。
我的动机来自于运行硒测试,其中每个测试彼此之间非常独立,但是它们需要时间。” </ p>
</ blockquote>

该线程包含有关实际好处的讨论。</ p>

它实际上仅是为了允许您运行不相关的长期运行的测试 与此同时。 它几乎没有在标准库中使用,因为几乎所有功能都需要尽可能快(某些加密异常等)。</ p>

还有进一步的讨论此处,提交是此处 </ p>
</ div>

展开原文

原文

This seems to have been brought up first on the golang-dev group.

The initial request states:

"I'd like to add an option to run tests in parallel with gotest. My motivation comes from running selenium tests where each test is pretty much independent from each other but they take time."

The thread contains the discussion of the practical benefits.

It's really just for allowing you to run unrelated, long-running tests at the same time. It's not really used in the standard library as almost all of the functionality needs to be as fast as possible (some crypto exceptions etc.)

There was further discussion here and the commit is here

dongyue4964
dongyue4964 我认为您的答案为std lib中缺乏普遍性提供了更好的理由。 第二个引号几乎总结了为什么它们没有通过std lib测试并“并行化”所有它们。
5 年多之前 回复
dooid3005
dooid3005 很好的发现,击败我的方法! :) +1
5 年多之前 回复



此线程(其中构思并讨论了 t.Parallel </ code>)表明 t.Parallel()</ code> 仅用于慢速测试; 平均测试是如此之快,以至于并行执行带来的任何收益都可以忽略不计。</ strong> </ p>

这里有一些引号(仅来自Russ,但没有太多反对意见):</ p>

Russ Cox [链接]:</ p>


关于以下问题 正确的默认设置是什么。
我们的大多数测试运行得如此之快,因此不需要并行化。 我认为这可能是正确的模型,
建议并行化是例外,
不是规则。
作为例外,可以使用测试可以使用的
t.Parallel()
方法来容纳 调用以声明可以与其他测试并行运行。</ p>
</ blockquote>

Russ Cox再次[链接]:</ p>


非并行测试 应该很快。

如果两项测试的速度很慢,那么您就可以将它们并行。
如果一项测试的速度很慢,那么,一项测试就很慢。</ p>
</ blockquote>

</ div>

展开原文

原文

This thread (in which t.Parallel is conceived and discussed) indicates that t.Parallel() is intended to be used for slow tests only; average tests are so fast that any gain from parallel execution would be negligible.

Here are some quotes (only from Russ, but there wasn't much opposition):

Russ Cox [link]:

There is some question about what the right default is. Most of our tests run so fast that parallelizing them is unnecessary. I think that's probably the right model, which would suggest parallelizing is the exception, not the rule. As an exception, this can be accommodated having a t.Parallel() method that a test can call to declare that it is okay to run in parallel with other tests.

Russ Cox again [link]:

the non-parallel tests should be fast. they're inconsequential. if two tests are slow, then you can t.Parallel them if it bothers you. if one test is slow, well, one test is slow.

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问