Parallel execution of unittests

[Jonathan M Davis via Digitalmars-d]

On Thu, 01 May 2014 07:26:59 +0000
Dicebot via Digitalmars-d <digitalmars-d at puremagic.com> wrote:

> On Thursday, 1 May 2014 at 04:50:30 UTC, Jonathan M Davis via 
> Digitalmars-d wrote:
> > std.file's unit tests would break immediately. It wouldn't 
> > surprise me
> > if std.socket's unit tests broke. std.datetime's unit tests 
> > would
> > probably break on Posix systems, because some of them 
> > temporarily set
> > the local time zone - which sets it for the whole program, not 
> > just the
> > current thread (those tests aren't done on Windows, because 
> > Windows only
> > lets you set it for the whole OS, not just the program). Any 
> > tests which
> > aren't pure risk breakage due to changes in whatever global, 
> > mutable
> > state they're accessing.
> 
> We really should think about separating Phobos tests into unit 
> tests and higher level ones (in separate top-level source folder).
> 
> The fact that importing std.file in my code with `rdmd -unittest` 
> may trigger file I/O makes me _extremely_ disgusted. How did we 
> even get here? >_<

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