std.unittests vote tally

[Nick Sabalausky]

"Jonathan M Davis" <jmdavisProg at gmx.com> wrote in message 
news:mailman.1401.1297185535.4748.digitalmars-d at puremagic.com...
> 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.
>

This is why I've always felt that assert/assertPred/etc should always check 
whether an exception was thrown and report it accordingly. That way, the 
test to make sure the result is correct will *automatically* provide all the 
benefits of assertNotThrown, but without the developer needing to 
compulsively "assertNotThrown" every single function they write/test.

However, that said, I think assertNotThrown would still be useful for void 
functions since those don't have a result to assert().

Plus, AIUI, assertNotThrown lets you make sure that a *specific* type of 
exception isn't thrown for the given arguments, which I can imagine would be 
useful in certain cases (for instance, if a function had been throwing the 
wrong type of exception upon bad input and you want to prevent regressions).