On Thu, Feb 3, 2011 at 10:32 AM, David Chelimsky <dchelim...@gmail.com>wrote:
> On Feb 3, 2011, at 9:28 AM, David Kahn wrote:
>
> On Thu, Feb 3, 2011 at 8:48 AM, Scott Taylor <sc...@railsnewbie.com>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?
>
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
>
>
>
>>
>> Scott
>>
>> On Feb 3, 2011, at 9:18 AM, David Kahn wrote:
>>
>> > 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:in `block in autorun'F.............................
>> >
>> > Failures:
>> > ...
>> >
>> >
>> >
>> > David
>> > _______________________________________________
>> > rspec-users mailing list
>> > rspec-users@rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/rspec-users
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
