rspec users - Feb 2011 - Is there a way to tell rspec not to fail the test while in debugger?

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 at
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110203/4a1dc870/attachment.html>

Probably manually rescuing your debugger call would work:

begin
  debugger
rescue Exception
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 at
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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On Thu, Feb 3, 2011 at 8:48 AM, Scott Taylor <scott at 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.

>
> 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 at
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 at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110203/ad1d873d/attachment.html>

On Feb 3, 2011, at 9:28 AM, David Kahn wrote:
> On Thu, Feb 3, 2011 at 8:48 AM, Scott Taylor <scott at
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?
>  
> 
> 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 at
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 at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110203/441c0234/attachment.html>

On Thu, Feb 3, 2011 at 10:32 AM, David Chelimsky <dchelimsky at
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 <scott at
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 at
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 at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/rspec-users
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110203/7dd097fe/attachment-0001.html>

On Feb 3, 2011, at 11:04 AM, David Kahn wrote:
> 
> 
> On Thu, Feb 3, 2011 at 10:32 AM, David Chelimsky <dchelimsky at
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 <scott at
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.
>  
> 
>>  
>> 
>> 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 at
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 at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110203/53e26701/attachment.html>

On Feb 3, 2011, at 12:04 PM, David Kahn wrote:
> 
> 
> On Thu, Feb 3, 2011 at 10:32 AM, David Chelimsky <dchelimsky at
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 <scott at
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 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
> 
> 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 at
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 at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>> 
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110203/21495ff1/attachment.html>

On Thu, Feb 3, 2011 at 11:24 AM, David Chelimsky <dchelimsky at
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 <dchelimsky at
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 <scott at
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 at
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 at rubyforge.org
>>> > http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20110203/cbd30d77/attachment-0001.html>