From: Edwin Fine <efine145-nospam01@...>
Date: 2006-11-21T07:58:58+09:00
Subject: Re: assert_raise question

unknown wrote:
> +1 again.
> 
> A big part of UT is to allow ease of refactoring.  Part of refactoring
> is, IMO, making exceptions more specific (eg from raise "No record
> found" to raise DBException, "No record found") and the like.
> 
> Having to change your UT's when you want to refactor is a bit self
> defeating.

Agreed.

Another +1. The whole point of having an exception hierarchy is so that 
you can specify a parent exception class at the interface level. You do 
this so that as your software grows, you can add new sub-exceptions 
without breaking your unit tests or your client's code. Sometimes you 
are interested in the actual exception, but sometimes you just want to 
catch the more general exception and don't care what the specific class 
is.

Here's an example:

begin
   eval(some text)
rescue ScriptError => e
   # Handle the script error
end

Do we always care if it was a ScriptError descendant (shown below)?

   LoadError
   NotImplementedError
   SyntaxError

No. Not always. Maybe not even in a unit test. Maybe the unit test 
starts off more general, and then as time goes by gets refined to test 
the exact exceptions.

I believe it's better to allow the users of general library code to use 
it the way that suits them best. So, I suggest adding another assertion 
method, assert_raise_s, which will succeed if the argument class of the 
raised exception is derived from (<=) the expected class. That way, you 
can have both a strict assertion (assert_raise) and the more general 
case (assert_raise_s).

In the meantime, I will just add a local assert_raise_s because, thanks 
to Matz, Ruby classes are open to extension.

-- 
Posted via http://www.ruby-forum.com/.