[Rspec-devel] Feature requests

aslak hellesoy aslak.hellesoy at gmail.com
Mon Aug 21 18:06:37 EDT 2006


On 8/21/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
> 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?
>

1) get the latest rspec sources with subversion
(http://rubyforge.org/scm/?group_id=797)
2) make sure you can build it successfully (rake pre_commit). See README.
3) modify your local working copy until it exhibits the misbehaviour
you're talking about
4) svn diff > reproduce_stacktrace_bug.patch
5) create a new ticket at rubyforge and attach the patch file

So what do you do in step 3? The simplest is probably to modify some
of the files under examples (or maybe add a new one) and run bin/spec
examples until you get the ugly stack traces you're talking about.

> 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.
>

I'm still confused. You do want stack traces to be printed yes? But
you want parts of the stack trace to be stripped away? Again - RSpec
already tries to strip parts of it away. If there are still parts of
the stack trace you would like RSpec to strip away we need some code
to reproduce it (and add extra stripping logic).

> >> 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.
>

I see what you mean. It would be even better if we could say:
{:foo => :bar}.should_have_key(:foo)

We'd have to add some grammatical rules to recognise common infinitive
verbs and try out their present form. Dave Astels actually showed me a
hack to do that yesterday.

This would be general, so if you have a method is_funny? then you can
say should_be_funny etc.

Cheers,
Aslak

> Judson
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


More information about the Rspec-devel mailing list