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 [EMAIL PROTECTED] >> @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 syntax. Scott _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
