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
