Start ruby debugger if rspec test fails

Question

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.

Answer 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)>

Answer 2

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

Answer 3

From the Rspec documentation:

RSpec tries to provide useful failure messages, but for cases in which you want more specific information, you can define your own message right in the example.This works for any matcher other than the operator matchers.

What I do is to invoke pry in that message. See the example:

describe "failing" do
  context "test" do
    it "should start pry" do
      a = 3
      b = 1
      expect(a).to be == b, "#{require 'pry';binding.pry}"
    end
  end
end

Happy debugging!

Answer 4

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.

Answer 5

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

Answer 6

You can use plymouth gem https://github.com/banister/plymouth for that. It is using pry though, a (better) alternative to irb.

HTH

Answer 7

You can try hammertime. It will stop and prompt to take you into an interactive debugging session whenever an exception is raised.