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.
