Parallel execution of unittests

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 30 14:35:45 PDT 2014


On 4/30/14, 2:25 PM, Jonathan M Davis via Digitalmars-d wrote:
> 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.

Agreed. I think we should look into parallelizing all unittests. -- Andrei


More information about the Digitalmars-d mailing list