Proposed new feature: Drop to debugger on failed test

ruby-talk
1

I'd like to propose a simple new feature which I think could be very
useful.

When a unit test fails, automatically raise the debugger.

Implementation should be simple - instead of just throwing errors on
failed assertions, do a require 'debug.rb'; raise (the exception again)

One issue I have is that this will be annoying for TDD, when we expect
tests to fail. So there needs to be some type of switch (envariable,
command line, etc.)

I'd appreciate comments and suggestions on this.

2

Or, you could simply use the breakpoint library...
Catch your own failure and drop yourself to an IRB session...
j.

···

On 11/21/05, nobuyoshi nakada <nobuyoshi.nakada@ge.com> wrote:

Hi,

At Tue, 22 Nov 2005 16:12:24 +0900,
listrecv@gmail.com wrote in [ruby-talk:166936]:
> When a unit test fails, automatically raise the debugger.
>
> Implementation should be simple - instead of just throwing errors on
> failed assertions, do a require 'debug.rb'; raise (the exception again)
>
> One issue I have is that this will be annoying for TDD, when we expect
> tests to fail. So there needs to be some type of switch (envariable,
> command line, etc.)

Create autodebug.rb like as:
module Kernel
alias _raise raise
def raise(*a)
require "debug"
_raise(*a)
end
end

then

$ ruby -rautodebug test_foo.rb

or

$ RUBYOPT=rautodebug testrb foo # for directories

--
Nobu Nakada

--
"Remember. Understand. Believe. Yield! -> http://ruby-lang.org"

Jeff Wood

3

listrecv@gmail.com wrote:

I'd like to propose a simple new feature which I think could be very
useful.

When a unit test fails, automatically raise the debugger.

I have thought about doing it with ruby-breakpoint, but it turned out that I would have to replace the definition of all the assertion methods from Test::Unit which was a bit too much overhead.

If anyone has a better idea of how to accomplish this I would be very happy to integrate it.

4

How about adding your own initialize to AssertionFailedError?

    class AssertionFailedError < StandardError
      def initialize(*a)
        super(*a)
        # Do your stuff here
      end
    end

Ryan

···

On 11/22/05, Florian Groß <florgro@gmail.com> wrote:

I have thought about doing it with ruby-breakpoint, but it turned out
that I would have to replace the definition of all the assertion methods
from Test::Unit which was a bit too much overhead.

If anyone has a better idea of how to accomplish this I would be very
happy to integrate it.

5

Ryan Leavengood wrote:

I have thought about doing it with ruby-breakpoint, but it turned out
that I would have to replace the definition of all the assertion methods
from Test::Unit which was a bit too much overhead.

If anyone has a better idea of how to accomplish this I would be very
happy to integrate it.

How about adding your own initialize to AssertionFailedError?

    class AssertionFailedError < StandardError
      def initialize(*a)
        super(*a)
        # Do your stuff here
      end
    end

Hm, do I have access to the type of the failed assertion from there?

6

Not really...are you sure do you need it?

AssertionFailedError.new is only called in one place, assert_block,
which is what is called by all the other assertions. So maybe you
could also override or alias assert_block.

But I'm not exactly sure what you are trying to do. But I can't
imagine something being impossible given the flexibility of the
Test::Unit code.

Ryan

···

On 11/22/05, Florian Groß <florgro@gmail.com> wrote:

Hm, do I have access to the type of the failed assertion from there?

7

Ryan Leavengood wrote:

>>Hm, do I have access to the type of the failed assertion from there?
>
> Not really...are you sure do you need it?
>
> AssertionFailedError.new is only called in one place, assert_block,
> which is what is called by all the other assertions. So maybe you
> could also override or alias assert_block.

Basically it would be wonderful to have that information as part of the reason why the breakpoint was triggered. Last time I checked the problem was that as soon as the methods to through a central place that kind of information is already lost.

Sure, it's not that critical a thing and I will probably still do this, but it would be nice to have a bit more information available.

Thanks for the information!