[Rspec-devel] Feature requests
nyarly-rspec at redfivellc.com
Mon Aug 21 16:54:03 EDT 2006
aslak hellesoy wrote:
> On 8/16/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
>> I've run into a couple of minor irritations working with rspec recently.
>> Mostly, I really like working with rspec. Tidy DSL, good Rake
>> integration, built in mocks and coverage are all major boons. But:
>> proc.should_raise and should_not_raise both result in printing the
>> backtrace of the the RSpec failure they raise, rather than the
>> unexpected exception that was raised. This leads to a fair amount of
>> extra dev time spent hunting down the error, where a message along the
>> lines of "proc should not have raised, but instead raised:" and the
>> whole exception (not the standard Ruby "...400 lines skipped that
>> include the line you care about..." :)
> Could you please submit an RFE for this? Preferrably in the form of a
> patch that we can apply and reproduce what you're getting. I'm not
> sure how you're getting 400 lines of trace. Are you on Rails? In that
> case - you can write the patch against the semo app under
I'll certainly submit an RFE. I'm not sure I follow the idea of
submitting a patch though - I could probably bung up a spec file that
would demonstrate what I'm talking about. And I could probably submit a
patch that would produce the behavior I'd like. Do you mean both?
The "400 lines" was a bit of an exaggeration. But I do a fair about of
DRb programming, which produces pretty deep call chains, which get cored
by the ruby interpreter when they're printed. The standard (read:
matz's) solution is to wrap the whole app in a "rescue Exception => e"
and print the backtrace explicitly. For development, this winds up
being incredibly handy, and it'd be nice if spec provided this behavior
>> Contrarywise, other expectations also print their entire backtrace,
>> which is rarely helpful and consumes a fair amount of scrollback and
> Really? We're stripping off most of the backtraces already. See spec's
> -b command line option. How can I reproduce a long backtrace as you
Under -f s, spec generates output of the form
- should do the right thing (FAILED - 1)
1) Spec::Api::ExpectionNotMet -
"a thing" should be "another thing"
<Backtrace goes here>
without -b. Forgive inconsistencies in the sample output: it's typed
>> Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?)
>> as do similar predicates (i.e. anything with an underscore).
> You can do this with should_include(:key)
Certainly, but while I've come to like the way that TDD/BDD drives
development in ways you wouldn't expect, a don't know if I like the idea
of never writing a two word predicate again. Hash#has_key? was a good
example, but hardly the only one.
More information about the Rspec-devel