Forum: Ruby Proposed new feature: Drop to debugger on failed test

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ccfe7d097475a32dc3ff78d6fc42c852?d=identicon&s=25 listrecv (Guest)
on 2005-11-22 08:14
(Received via mailing list)
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.
04a56914cc09f0858d3fca2bf4cbde34?d=identicon&s=25 nobuyoshi.nakada (Guest)
on 2005-11-22 08:26
(Received via mailing list)
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
A7c9c275318af9e1e3812fab9660cd7c?d=identicon&s=25 jeff.darklight (Guest)
on 2005-11-22 17:38
(Received via mailing list)
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:
> > 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 Wood
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 florgro (Guest)
on 2005-11-22 18:26
(Received via mailing list)
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.
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 leavengood (Guest)
on 2005-11-22 18:38
(Received via mailing list)
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.

How about adding your own initialize to AssertionFailedError?

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

Ryan
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 florgro (Guest)
on 2005-11-22 19:59
(Received via mailing list)
Ryan Leavengood 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?
4b174722d1b1a4bbd9672e1ab50c30a9?d=identicon&s=25 leavengood (Guest)
on 2005-11-22 20:59
(Received via mailing list)
On 11/22/05, Florian Groß <florgro@gmail.com> 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
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 florgro (Guest)
on 2005-11-22 23:00
(Received via mailing list)
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!
C1bcb559f87f356698cfad9f6d630235?d=identicon&s=25 Hal Fulton (Guest)
on 2005-12-19 08:25
(Received via mailing list)
nobuyoshi nakada wrote:
> Hi,
>
> At Sat, 17 Dec 2005 15:42:18 +0900,
> Hal Fulton 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
This topic is locked and can not be replied to.