Parallel execution of unittests

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 30 14:25:22 PDT 2014


On Wed, 30 Apr 2014 13:26:40 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>
wrote:

> On 4/30/14, 10:50 AM, Jonathan M Davis via Digitalmars-d wrote:
> > There
> > is nothing whatsoever in the language which guarantees that running
> > them in parallel will work or even makes sense.
> 
> Default thread-local globals? -- Andrei

Sure, that helps, but it's trivial to write a unittest block which
depends on a previous unittest block, and as soon as a unittest block
uses an external resource such as a socket or file, then even if a
unittest block doesn't directly depend on the end state of a
previous unittest block, it still depends on external state which could
be affected by other unittest blocks. So, ultimately, the language
really doesn't ensure that running a unittest block can be
parallelized. If it's pure as bearophile suggested, then it can be
done, but as long as a unittest block is impure, then it can rely on
global state - even inadvertently - (be it state directly in the program
or state outside the program) and therefore not work when pararellized.
So, I suppose that you could parallelize unittest blocks if they were
marked as pure (though I'm not sure if that's currently a legal thing
to do), but impure unittest blocks aren't guaranteed to be
parallelizable.

I'm all for making it possible to parallelize unittest block
execution, but as it stands, doing so automatically would be a bad
idea. We could make it so that a unittest block could be marked as
parallelizable, or we could even move towards making parallelizable the
default and require that a unittest block be marked as
unparallelizable, but we'd have to be very careful with that, as it
will break code if we're not careful about how we do that transition.

I'm inclined to think that marking unittest blocks as pure to
parallelize them is a good idea, because then the unittest blocks that
are guaranteed to be parallelizable are run in parallel, whereas those
that aren't wouldn't be. The primary dowside would be that the cases
where the programmer knew that they could be parallelized but they
weren't pure, since those unittest blocks wouldn't be parallelized.

- Jonathan M Davis


More information about the Digitalmars-d mailing list