[Rspec-devel] Feature requests

aslak hellesoy aslak.hellesoy at gmail.com
Wed Aug 16 00:41:37 EDT 2006

On 8/15/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..." :)
> Contrarywise, other expectations also print their entire backtrace,
> which is rarely helpful and consumes a fair amount of scrollback and
> attention.
> Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?)
> as do similar predicates (i.e. anything with an underscore).
> It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> as an expectation to be called at least 3 times, and warn if they were
> told otherwise - it's certainly not Least Surprise when the class being
> specced against fails because it's getting the wrong result.
> Am I the voice in the wilderness here?


> I'm more than willing to submit
> patches, if there's some chance they'll be accepted.


Bring on the patches in our tracker at Rubyforge. You don't have to
provide a fix (although it's nice if you do). The most important is
some code that would allow us to reproduce a long and ugly backtrace.
We'd be able to fix that fairly quickly.


> 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