Parallel execution of unittests

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Mon May 5 08:55:01 PDT 2014


On Monday, 5 May 2014 at 15:36:19 UTC, Andrei Alexandrescu wrote:
> On 5/5/14, 8:11 AM, Dicebot wrote:
>> On Thursday, 1 May 2014 at 16:08:23 UTC, Andrei Alexandrescu 
>> wrote:
>>>> It got full because of tests (surprise!). Your actions?
>>>
>>> Fix the machine and reduce the output created by the 
>>> unittests. It's a
>>> simple engineering problem. -- Andrei
>>
>> You can't. You have not control over that machine you don't 
>> even exactly
>> know that test has failed because of full /tmp/ - all you got 
>> is a bug
>> report that can't be reproduced on your machine.
>>
>> It is not that simple already and it can get damn complicated 
>> once you
>> get to something like network I/O
>
> I know, incidentally the hhvm team has had the same problem two 
> weeks ago. They fixed it (wthout removing file I/O from 
> unittests). It's fixable. That's it.

It is possible to write a unit test which provides graceful 
failure reporting for such issues but once you get there it 
becomes hard to see actual tests behind boilerplate of 
environmental verification and actual application code behind 
tests.

Any tests that rely on I/O need some sort of commonly repeated 
initialize-verify-test-finalize pattern, one that is simply 
impractical to do with unit tests.

> This segment started with your claim that unittests should do 
> no file I/O because they may fail with a full /tmp/. I disagree 
> with that, and with framing the full /tmp/ problem as a problem 
> with the unittests doing file I/O.

It was just a most simple example. "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.

Full /tmp is not a problem, there is nothing broken about system 
with full /tmp. Problem is test reporting that is unable to 
connect failure with /tmp being full unless you do environment 
verification.


More information about the Digitalmars-d mailing list