"Jonathan M Davis" <jmdavisp...@gmx.com> wrote in message news:mailman.1401.1297185535.4748.digitalmar...@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).
