[rspec-users] Failure Messages in RSpec + inline debugging of a spec

Scott Taylor mailing_lists at railsnewbie.com
Sat Sep 8 16:19:23 EDT 2007

On Sep 5, 2007, at 4:25 AM, Wincent Colaiuta wrote:

> El 4/9/2007, a las 22:51, Geoffrey Wiseman escribió:
>> Using this as an example, if a new validation rule is added, this
>> test will
>> fail without indicating /why/.  Sure, I can get that answer in
>> other ways,
>> but I'd hate to discover things like:
>> it "should be valid with valid attributes" do
>>   # puts @person.errors if !@person.valid
>>   @person.should be_valid
>> end
>> (Which I've seen when people have to repeatedly diagnose issues in
>> a test;
>> I'd prefer a failure message to the above)
> My personal approach when a spec fails and I can't figure out *why*
> just by looking at it is to run the spec under the debugger and set a
> breakpoint on the line where the corresponding spec fails.

I've been doing the same thing with ruby-debug.  I have setup a  
snippet in textmate so that when I type debug(tab), I get the  
following line:

require 'rubygems'; require 'ruby-debug'; debugger

And I usually do this *inside* the failing spec.  So far it has been  
a mixed experience - I have found that it doesn't work very well with  
rails as you end up debugging more of rails then of your own code.   
It also doesn't work with the DRB server.

Any thoughts on how this could be better done?

> I actually *like* the way that RSpec doesn't provide a mechanism for
> specifying error messages; it's one of the things that makes the
> specs so easy to read. It's difficult to imagine a syntax that would
> provide what you're asking for without sacrificing readability.
> Cheers,
> Wincent

I couldn't agree more.  I, like David, am not opposed to a custom  
matcher, but it's hard to imagine how it would play nicely with the  


More information about the rspec-users mailing list