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