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