Parallel execution of unittests

[Jonathan M Davis via Digitalmars-d]

On Wed, 30 Apr 2014 21:09:14 +0100
Russel Winder via Digitalmars-d <digitalmars-d at 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?

There is nothing in the language which has ever mandated that unittest
blocks be parallelizable or that they be pure (which is essentially
what you're saying all unittest blocks should be). And restricting
unittest blocks so that they have to be pure (be it conceptually pure
or actually pure) would be a _loss_ of functionality.

Sure, let's make it possible to parallelize unittest blocks where
appropriate, but I contest that we should start requiring that unittest
blocks be pure (which is what a function has to be in order to be
pararellized whether it's actually marked as pure or not). That would
force us to come up with some other testing mechanism to run those
tests when there is no need to do so (and I would argue that there is
no compelling reason to do so other than ideology with regards to what
is truly a "unit" test).

On the whole, I think that unittest blocks work very well as they are.
If we want to expand on their features, then great, but let's do so
without adding new restrictions to them.

- Jonathan M Davis