Parallel execution of unittests

[Dicebot via Digitalmars-d]

On Thursday, 1 May 2014 at 07:47:27 UTC, Jonathan M Davis via 
Digitalmars-d wrote:
> Honestly, I see no problem with std.file's unit tests 
> triggering I/O.
> That's what the module _does_. And it specifically uses the 
> system's
> temp directory so that it doesn't screw with anything else on 
> the
> system. Separating the tests out into some other set of tests 
> wouldn't
> buy us anything IMHO. The tests need to be run regardless, and 
> they
> need to be run with the same frequency regardless. Splitting 
> those
> tests out would just make them harder for developers to run, 
> because
> now they'd have to worry about running two sets of tests 
> instead of
> just one. As far as I can see, splitting out tests that do I/O 
> would be
> purely for ideological reasons and would be of no practical 
> benefit. In
> fact, it would be _less_ practical if we were to do so.
>
> - Jonathan M Davis

I have just recently went through some of out internal projects 
removing all accidental I/O tests for the very reason that /tmp 
was full and those tests were randomly failing when testing my 
own program that have used the library. This _sucks_. You can't 
do any test with I/O without verifying the environment (free 
space, concurrent access from other processes, file system access 
etc). And once you do it properly such beast has no longer fits 
into the same module because of sheer size.

There is a very practical reason to separate tests - to become 
sure that you always can run -unittest build to verify basic 
sanity of your program and it will never spuriously fail or take 
eternity to complete.