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.
