Parallel execution of unittests

[Dicebot via Digitalmars-d]

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 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?

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.