std.unittests vote tally

[Jonathan M Davis]

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