RSpec showing full backtrace by default #798

Closed
sferik opened this Issue Feb 23, 2013 · 9 comments

3 participants

@sferik

I'm getting a full backtrace (including rspec code) even though I'm not passing the --backtrace option.

Screen Shot 2013-02-23 at 12 18 35 PM

You should be able to reproduce by cloning thor, adding a failing spec, and running the specs.

git clone git://github.com/wycats/thor.git
cd thor
bundle install
# Add a failing expectation
bundle exec thor spec
@sferik

Apparently this is a dupe of #754. It looks like it's happening because I keep my development gems in ~/Projects/Ruby/gems. Is there any workaround that doesn't require renaming my directory tree?

Could you add a --no-backtrace flag that I could put in my global ~/.rspec file?

@sferik

I was able to workaround the issue by renaming my directory and creating a symlink called gems. I'm not in love with that solution, but it works. 😥

@sferik

It seems like you could whitelist the directory that the specs are being run from, no?

@myronmarston
RSpec member

Sorry about the trouble. Did my fix in 356f15a for #754 cause this?

Anyhow, your suggestions to add --no-backtrace and whitelisting the current directory both sound reasonable. I'll try to get to this soon.

@myronmarston
RSpec member

I meant to get to this right away, but have been busy with other issues. I think I've figured out the right solution here if someone wants to take a stab at this:

  • Extract a BacktraceCleaner object, as suggested by this comment.
  • This object should have both clean_patterns (which correspond to the current Configuration#backtrace_clean_patterns config option) and include_patterns (which will be new). The latter will specify a list of patterns for which any matching backtrace line will always be included in the backtrace, even if the line matches the clean_patterns.
  • This new include_patterns option will default to containing the current working directory (which should fix @sferik's issue), and also be exposed as a config option for end users to configure.

If anyone wants to take a stab at this, comment here so we know. If not, I'll try to get to it at some point.

@samphippen
RSpec member

@myronmarston I can probably build this out on sunday this week 😄.

@myronmarston
RSpec member

@samphippen -- sounds great, thanks for taking a stab at it!

@myronmarston
RSpec member

This got addressed by @samphippen in #843, which I've just merged.

@sferik -- want to give rspec master and shot and see if it works for your setup?

@sferik

I can confirm that this issue is fixed in master. 🚢 it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment