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?
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.)
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):
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.