[Rspec-devel] Feature requests

Judson Lester 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
> vendor/rspec_on_rails.
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
on backtraces.

>> Contrarywise, other expectations also print their entire backtrace,
>> which is rarely helpful and consumes a fair amount of scrollback and
>> attention.
> 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
> describe?
Under -f s, spec generates output of the form

A Context
- 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
from memory.

>> 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 mailing list