On Wednesday, 30 April 2014 at 21:49:06 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:
On Wed, 2014-04-30 at 11:19 -0700, Jonathan M Davis via
Digitalmars-d
wrote:
> unittest blocks just like any other unit test. I would very
> much
> consider std.file's tests to be unit tests. But even if you
> don't
> want to call them unit tests, because they access the file
> system,
> the reality of the matter is that tests like them are going
> to be
> run in unittest blocks, and we have to take that into
> account when
> we decide how we want unittest blocks to be run (e.g. whether
> they're parallelizable or not).
In which case D is wrong to allow them in the unittest blocks
and
should introduce a new way of handling these tests. And even
then all
tests can and should be parallelized. If they cannot be then
there is
an inappropriate dependency.
Why? Because Andrei suddenly proposed that we parallelize
unittest
blocks? If I want to test a function, I'm going to put a
unittest block
after it to test it. If that means accessing I/O, then it means
accessing I/O. If that means messing with mutable, global
variables,
then that means messing with mutable, global variables. Why
should I
have to put the tests elsewhere or make is that they don't run
whenthe
-unttest flag is used just because they don't fall under your
definition
of "unit" test?
You do this because unit tests must be fast. You do this because
unit tests must be naively parallel. You do this because unit
tests verify basic application / library sanity and expected to
be quickly run after every build in deterministic way (contrary
to full test suite which can take hours).
Also you do that because doing _reliably_ correct tests with I/O
is relatively complicated and one does not want to pollute actual
source modules with all environment checks.
In the end it is all about supporting quick edit-compile-test
development cycle.
