Parallel execution of unittests
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Mon May 5 11:58:43 PDT 2014
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
More information about the Digitalmars-d
mailing list