Is there a way to tell rspec not to fail the test while in debugger?

Testing RSpec
1

I am curious as with Test::Unit I could go into the debugger and stay
all
day inside of a test and make all kinds of errors without a problem.
With
rspec I experience that if I make a bad query/ActiveRecord call that it
flips out and fails the test, throwing me back to the command prompt.
This
is normally not a problem but getting rather annoying right now as I am
trying to work out some rather complex logic. Any ideas if there is a
way to
bypass this situation?

For example:

(rdb:1) TuRawBillDetail.includes(:account_subcode).select(“DISTINCT
account_product_id”)
INTERNAL ERROR!!! missing attribute: account_subcode_id
/Users/DK/.rvm/gems/ruby-1.9.2-p136@ncc_billing/gems/activerecord-3.0.3/lib/active_record/association_preload.rb:324:in
block in preload_belongs_to_association' ... re/runner.rb:10:inblock in autorun’F…

Failures:
…

David

2

On Thu, Feb 3, 2011 at 8:48 AM, Scott T. [email protected]
wrote:

Probably manually rescuing your debugger call would work:

begin
debugger
rescue Exception
end

Thanks, I just tried this but no go, the rspec still trips and fails me
out.
Maybe I have a really different methodology but I depend a lot on
working
stuff out in the debugger.

3

On Feb 3, 2011, at 9:28 AM, David K. wrote:

On Thu, Feb 3, 2011 at 8:48 AM, Scott T. [email protected] wrote:

Probably manually rescuing your debugger call would work:

begin
debugger
rescue Exception
end

Thanks, I just tried this but no go, the rspec still trips and fails me out.
Maybe I have a really different methodology but I depend a lot on working stuff
out in the debugger.

I actually do this sort of thing all the time, but I’ve never run into
the problem you’re talking about. The only thing I can think of is that
there is a message expectation in the spec that you’re triggering a
failure on (they fail fast whenever they can). Are you setting any
message expectations? Or using stubs of some kind?

4

Probably manually rescuing your debugger call would work:

begin
debugger
rescue Exception
end

Scott

5

On Thu, Feb 3, 2011 at 10:32 AM, David C.
[email protected]wrote:

end
fail fast whenever they can). Are you setting any message expectations? Or
using stubs of some kind?

No, at least nothing consciously as I am rather green overall at using
rspec. This seems to be happening across projects — I kind of took it
for
a necessary evil until now where it started eating into my time and
patience. In fact the spec where this was happening was just a one-liner
“Model.all.size.should == 3” or the like. This is my spec helper, if
that
helps:

This file is copied to spec/ when you run 'rails generate

rspec:install’
ENV[“RAILS_ENV”] ||= ‘test’
require File.expand_path(“…/…/config/environment”, FILE)
require ‘rspec/rails’
require ‘paperclip/matchers’

require Rails.root.join(‘db’,‘seeds’)

Requires supporting ruby files with custom matchers and macros, etc,

in spec/support/ and its subdirectories.

Dir[Rails.root.join(“spec/support/**/*.rb”)].each {|f| require f}

RSpec.configure do |config|
config.mock_with :rspec

Remove this line if you’re not using ActiveRecord or ActiveRecord

fixtures
config.fixture_path = “#{::Rails.root}/spec/fixtures”

If you’re not using ActiveRecord, or you’d prefer not to run each of

your

examples within a transaction, remove the following line or assign

false

instead of true.

config.use_transactional_fixtures = true

config.include Paperclip::Shoulda::Matchers
end

6

On Feb 3, 2011, at 11:04 AM, David K. wrote:

debugger
ENV[“RAILS_ENV”] ||= ‘test’
RSpec.configure do |config|
config.include Paperclip::Shoulda::Matchers
end

Everything looks normal there. Have you tried the same with test/unit
yet? If you haven’t, please do create a test case that does exactly the
same stuff and see if you can debug any differently. If that works, then
at least you have a way to work through this in the short run, and we
know something is up with rspec. If it doesn’t work, then we know the
problem is likely in some other part of the equation.

7

On Feb 3, 2011, at 12:04 PM, David K. wrote:

debugger
rescue Exception
end

Thanks, I just tried this but no go, the rspec still trips and fails me out.
Maybe I have a really different methodology but I depend a lot on working stuff
out in the debugger.

I do the same.

I’ve noticed that actually exiting out to irb will trip things up more
often then simple ‘p’ / ‘print’ statements, so I try to stay out of irb.

I’ve only really noticed the debugger itself crashing in rails projects

  • outside of rails, I’ve never had a problem.

Maybe the ruby-debug / trepanning guys can help you out more (I suspect
it’s more of a debugger / integration issue with rails than an rspec
one).

Cheers,

Scott

8

On Thu, Feb 3, 2011 at 11:24 AM, David C.
[email protected]wrote:

working stuff out in the debugger.
rspec. This seems to be happening across projects — I kind of took it for

fixtures
end

Everything looks normal there. Have you tried the same with test/unit yet?
If you haven’t, please do create a test case that does exactly the same
stuff and see if you can debug any differently. If that works, then at least
you have a way to work through this in the short run, and we know something
is up with rspec. If it doesn’t work, then we know the problem is likely in
some other part of the equation.

Ok, so I tried in test unit. What I found was mixed.

For example, the following line returned [] consistently in test::unit
without crashing while in rspec I got a crash and ‘INTERNAL ERROR!!!
missing
attribute: account_subcode_id’ (this line has a flaw in association,
which
makes sense to me but not why it kills me in rspec but test unit takes
it in
stride… weird):

TuRawBillDetail.includes(:account_subcode).select(“DISTINCT
account_product_id”)

Yet, this line (with a bad column) causes both rspec and test unit to
crash
right away:

TuRawBillDetail.includes(:account_subcodes).select(“DISTINCT
accounproduct_id”)