RE: exceptions and distinguishing between failures and er rors

> -----Original Message-----
> From: pholser [mailto:pholser@xxxxxxxxx]
> 
...
> 
> my gut tells me to treat "could be thrown but shouldn't" exceptions--
> that is, those advertised in the throws clauses of methods invoked
> in the test, plus any runtime exceptions known to be thrown under
> certain conditions (for example, IllegalArgumentException for
> integer arguments out of range)--as failures, and anything else as
> errors.  this goes for tests whose successful outcome doesn't involve
> the throwing of a specific exception, too.  i get the feeling most
> developers don't do that because they perceive the extra code
> involved to be too much of a whipping to create and maintain.
> or, the failure/error distinction is not important to them.  i've
> been trying to distinguish between failures and errors with these
> kinds of tests, and maybe i shouldn't be.
> 

 I often find that when some assertions fail, in different tests things go
wrong and generate errors.
 When I get a bunch of errors without failures, then I feel I miss some
tests or assertions. E.g. a method returning null when it is never supposed
to do that generates a NullPointerException somewhere, and the appropriate
test does not reveal that fact by failing.
 Otherwise, I wouldn't test the PossibleImprobableRuntimeException, it will
be reported anyway.

> i wonder if writing exception tests in this way can sniff out "smells"
> that using a particular method might be too noisy?  that is, instead
> of throwing three different, possibly unrelated exceptions, maybe
> have the method declare one wrapping exception be thrown?
> 

 The smell "Missed an aspect to test" ?