On Thu, Feb 3, 2011 at 11:24 AM, David Chelimsky <dchelim...@gmail.com>wrote:

> On Feb 3, 2011, at 11:04 AM, David Kahn wrote:
>
>
>
> 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
>
>
> 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")





>
>
>
>>
>>
>>
>>>
>>> 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
>
>
>
> _______________________________________________
> 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

Reply via email to