问题
Often, when a test fails, I spend quite sometime trying to figure out the what caused it to fail. It'd be useful if RSpec could kick off a Ruby debugger when the test fails, so that I can inspect the local variables immediately to drill down on the cause.
The work-around I'm using right now looks something like this:
# withing some test
debugger unless some_variable.nil?
expect(some_variable).to be_nil
However, this approach is cumbersome, because I first wait for a test to fail, then add the debugger line, fix the issue and then have to remove the debugger line, whereas I want it work more like gdb
which has the ability to kick in when an exception is hit, without requiring to pepper your code base with debugger
statements.
Edit: I've tried Plymouth. It hasn't worked reliably enough for me. Also the development history seems to indicate that it isn't a very well supported gem, so I'd rather not rely on it.
Update: I tried out pry-rescue
and find it to be neat. However, I use zeus a lot and was wondering if there's a way to make it work with pry-rescue
.
回答1:
Use pry-rescue, it's the spiritual successor to plymouth:
From the Readme:
If you're using RSpec or respec, you can open a pry session on every test failure using rescue rspec or rescue respec:
$ rescue rspec
From: /home/conrad/0/ruby/pry-rescue/examples/example_spec.rb @ line 9 :
6:
7: describe "Float" do
8: it "should be able to add" do
=> 9: (0.1 + 0.2).should == 0.3
10: end
11: end
RSpec::Expectations::ExpectationNotMetError: expected: 0.3
got: 0.30000000000000004 (using ==)
[1] pry(main)>
回答2:
You won't get access to local variables (easily) without debugger
being in scope of the block, however RSpec
provides you with around hooks which let's you do this:
config.around(:each) do |example|
result = example.run
debugger if result.is_a?(Exception)
puts "Debugging enabled"
end
You then have access to @ivars
and subject
/ let(:var)
contents at this point.
回答3:
I like @jon-rowe's solution (no additional gems needed) with a slight edit: I really don't care about other errors as much as RSpec::Expectations::ExpectationNotMetError
.
config.around(:each) do |example|
example.run.tap do |result|
debugger if result.is_a?(RSpec::Expectations::ExpectationNotMetError)
end
end
回答4:
You need to catch the ExpectationNotMatched exception while it's being constructed. Include the following code in your helpers somewhere and RSpec will stop when the exception is being constructed. This will be several levels deep inside the matchers, so in the debugger, say "where" then "up 5"or "up 6" and you'll be inside the instance_exec of your block. The debugger doesn't show the code correctly in the version I'm using, but you can "up" one more time and get to code running in the same context where your test is evaluated, so you can inspect the instance variables (but not local variables, it seems).
require 'debugger'
require 'rspec'
Debugger.start
class RSpec::Expectations::ExpectationNotMetError
alias_method :firstaid_initialize, :initialize
def initialize *args, &b
send(:firstaid_initialize, *args, &b)
puts "Stopped due to #{self.class}: #{message} at "+caller*"\n\t"
debugger
true # Exception thrown
end
end
describe "RSpec" do
it "should load use exceptions on should failure" do
@foo = :bar # An instance variable I can examine
1.should == 2
end
end
回答5:
You can use plymouth gem https://github.com/banister/plymouth for that. It is using pry though, a (better) alternative to irb.
HTH
回答6:
You can try hammertime. It will stop and prompt to take you into an interactive debugging session whenever an exception is raised.
来源:https://stackoverflow.com/questions/16290365/start-ruby-debugger-if-rspec-test-fails