Proposed new feature: Drop to debugger on failed test

Ruby
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

Hi,

At Tue, 22 Nov 2005 16:12:24 +0900,
[email protected] 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

3

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 [email protected] wrote:

One issue I have is that this will be annoying for TDD, when we expect
end
Nobu Nakada

–
“Remember. Understand. Believe. Yield! → http://ruby-lang.org”

Jeff W.

4

On 11/22/05, Florian Groß [email protected] 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

Ryan

5

Ryan L. wrote:

  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

Ryan L. 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!

7

nobuyoshi nakada wrote:

Hi,

At Sat, 17 Dec 2005 15:42:18 +0900,
Hal F. wrote in [ruby-talk:171286]:

I think it’s just for looks, to emphasize that it’s a string.
Like String#inspect.

#dump ignores $KCODE, whereas #inspect is affected by it.

Very interesting. If I ever knew that, I forgot it.

That is the sort of information I am looking for as I learn more
about I18N.

Hal

8

[email protected] 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.

9

On 11/22/05, Florian Groß [email protected] 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.

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