Parallel execution of unittests

[Andrei Alexandrescu via Digitalmars-d]

On 5/5/14, 11:47 AM, Dicebot wrote:
> On Monday, 5 May 2014 at 18:29:40 UTC, Andrei Alexandrescu wrote:
>> My understanding here is you're trying to make dogma out of
>> engineering choices that may vary widely across projects and
>> organizations. No thanks.
>>
>> Andrei
>
> I am asking to either suggest an alternative solution or to clarify why
> you don't consider it is an important problem.

"Clean /tmp/ judiciously."

> Dogmatic approach that
> solves the issue is still better than ignoring it completely.

The problem with your stance, i.e.:

> "Unittests should do no I/O because any sort of I/O can fail because
> of reasons you don't control from the test suite" is an appropriate
> generalization of my statement.

is that it immediately generalizes into the unreasonable:

"Unittests should do no $X because any sort of $X can fail because of 
reasons you don't control from the test suite".

So that gets into machines not having any memory available, with full 
disks etc.

Just make sure test machines are prepared for running unittests to the 
extent unittests are expecting them to. We're wasting time trying to 
frame this as a problem purely related to unittests alone.

> Right now I am afraid you will push for quick changes that will reduce
> elegant simplicity of D unittest system without providing a sound
> replacement that will actually fit into more ambitious use cases (as
> whole "parallel" thing implies).

If I had my way I'd make parallel the default and single-threaded 
opt-in, thus penalizing unittests that had issues to start with. But I 
understand the merits of not breaking backwards compatibility so 
probably we should start with opt-in parallel unittesting.


Andrei