On 2/8/11 12:20 PM, Jonathan M Davis wrote:
On Tuesday, February 08, 2011 08:36:27 Andrei Alexandrescu wrote:
On 2/8/11 10:54 AM, Jonathan M Davis wrote:
Enhancement request for assert:
http://d.puremagic.com/issues/show_bug.cgi?id=5547
Thanks!
Okay. I'll look at doing another proposal which has the functionality of
assertPred which doesn't make sense to add to assert, though I'll
probably wait until the voting for assertNotThrown and
collectExceptionMsg is done.
I would point out, however, that it would be rather silly to include
assertThrown and not assertNotThrown. Good unit tests should test _both_
that a function succeeds as it's supposed to _and_ that it fails as it's
supposed to. So, I would hope that people vote in favor of
assertNotThrown.
True. But the test is clearer if you're explicitly testing that the function
doesn't throw instead of just having a stray function call that isn't tested.
For instance.
assertNotThrown!DateTimeException(TimeOfDay(23, 59, 59));
is clearer than
TimeOfDay(23, 59, 59);
In the first case, it's clear that you're testing that the function call does
not
throw. In the second, it's a function call that seems to do nothing, since its
result isn't saved, it takes no references, and it's not part of an assert.
Also, the first one results in an AssertError that clearly states that the
problem is that the function threw when it wasn't supposed to, whereas in the
second, you just get a stray exception which is likely going to be a bit hard to
track down - even with a stack trace - because the unit test blocks get named
with seemingly random numbers rather than real names and tracking down which
unittest block an exception was thrown from is a royal pain (one more reason why
we really should have named unit tests).
So, I think that assertNotThrown definitely helps with clarity, and it makes it
much easier to track down the failure.
- Jonathan M Davis
I think I'd write that as
assert(!collectException(TimeOfDay(23, 59, 59));
Andrei
