std.unittests vote tally

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Feb 8 16:30:20 PST 2011


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


More information about the Digitalmars-d mailing list