Parallel execution of unittests

[H. S. Teoh via Digitalmars-d]

On Wed, Apr 30, 2014 at 02:25:22PM -0700, 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.

In this case I'd argue that the test was poorly-written. I can see
multiple unittests using, say, the same temp filename for testing file
I/O, in which case they shouldn't be parallelized; but if a unittest
depends on a file created by a previous unittest, then something is
very, very wrong with the unittest.


[...]
> 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.

Agreed.


> 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.
[...]

Is it a big loss to have *some* unittests non-parallelizable? (I don't
know, do we have hard data on this front?)


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL