Forum: Ruby-core Mini Unit changing exceptions

Why does mini-unit change the exception in the test below?

--start code----------------------------------------
require 'test/unit'

def epic_fail
   fail RuntimeError.new("Oops")
end

class FailureTest < Test::Unit::TestCase
   def test_failure
     epic_fail
   rescue Exception => ex
     puts "Expecting RuntimeError, got: #{ex.class}"
   end
end
--end code----------------------------------------

Here's the output:

    $ ruby19 test_fail.rb
    Loaded suite test_fail
    Started
    Expecting RuntimeError, got: Mini::Assertion
    .
    Finished in 0.000435 seconds.

    1 tests, 1 assertions, 0 failures, 0 errors

On Sep 24, 2008, at 23:20 , Jim Weirich wrote:

>  fail RuntimeError.new("Oops")

     def fail msg = nil
       msg ||= "Epic Fail!"
       assert false, msg
     end

you're passing a RuntimeError instance as the message.

    fail "Oops"

is the right way to do that.

On Sep 25, 2008, at 3:13 AM, Ryan Davis wrote:
>
>   fail "Oops"
>
> is the right way to do that.

Hmmmm...  It seems bad form to change the semantics of a kernel
defined method. (http://ruby-doc.org/core/classes/Kernel.html#M005954)

Nevertheless, it does seem to have found a weakness in my tests where
I've allowed Mini::Assertions to accidently leak into the code that
I'm testing. (The above was a simplified version of a real problem I
ran into where the fail call was not directly in a test module and was
intending to invoke the kernel version, not the mini-test version).

Even so, I'm not entirely happy with the overriding of a kernel
method, even if it is only in test case code.

On Sep 25, 2008, at 05:21 , Jim Weirich wrote:

>> you're passing a RuntimeError instance as the message.
>>
>>  fail "Oops"
>>
>> is the right way to do that.
>
> Hmmmm...  It seems bad form to change the semantics of a kernel  
> defined method. (http://ruby-doc.org/core/classes/Kernel.html#M005954)

omg... I never even knew that existed. I've never seen any code that
ever used it. heh. you learn something new every day. :P

On Sep 25, 2008, at 3:12 PM, Ryan Davis wrote:

> omg... I never even knew that existed. I've never seen any code that  
> ever used it. heh. you learn something new every day. :P

I'm probably one of the few that uses it regularly.  I use :fail to
when I wish to emphasize that a method has failed in some way (e.g.
cannot meeting a post condition is a failure and I would use :fail).
I use raise when I'm dealing with the semantics of raising exceptions
(e.g. code that catches an exception and re-raises it would use :raise
rather than :fail).

I'm quite pleased that Ruby allows me such fine nuances of expression
in my code.

On Sep 25, 2008, at 13:11 , Jim Weirich wrote:

> I'm probably one of the few that uses it regularly.  I use :fail to  
> when I wish to emphasize that a method has failed in some way (e.g.  
> cannot meeting a post condition is a failure and I would  
> use :fail).  I use raise when I'm dealing with the semantics of  
> raising exceptions (e.g. code that catches an exception and re- 
> raises it would use :raise rather than :fail).

*nod*

how/why are you using it w/in tests?

maybe I should rename "fail" to "suck" :P

On Sep 25, 2008, at 4:53 PM, Ryan Davis wrote:

> how/why are you using it w/in tests?

Short version: I'm testing a module that is designed to be included
into other classes.  So I just included it into the test class and
called the methods to be tested.  So when the method under test calls
fail, it gets the overridden version in Mini::Assertion.  Now that I
know what's happening I can fix it, but it was a bit confusing for a
while.