Uruchom debugger ruby, jeśli test rspec nie powiedzie się

Question

Często, gdy test kończy się niepowodzeniem, spędzam całkiem sporo czasu, próbując dowiedzieć się, co spowodowało jego niepowodzenie. Byłoby użyteczne, gdyby RSpec mógł uruchomić debugger w języku Ruby, gdy test się nie powiedzie, tak żebym mógł natychmiast sprawdzić zmienne lokalne, aby poznać przyczynę.

Prace wokół używam teraz wygląda mniej więcej tak:

# withing some test 
debugger unless some_variable.nil? 
expect(some_variable).to be_nil 

Jednak takie podejście jest uciążliwe, bo najpierw czekać na test się nie powiedzie, a następnie dodać linię debugger, Fix problem, a następnie trzeba usunąć linię debuggera, podczas gdy ja chcę, aby działała bardziej jak gdb, która ma możliwość uruchomienia w momencie trafienia wyjątku, bez konieczności pieprzenia bazy kodu z instrukcjami debugger.

Edytuj: Próbowałem Plymouth. Nie zadziałało to dla mnie wystarczająco dobrze. Również historia rozwoju wydaje się wskazywać, że nie jest to bardzo dobrze zachowany klejnot, więc wolałbym na nim nie polegać.

Aktualizacja: Wypróbowałem pry-rescue i znalazłem go w porządku. Jednak często używam zeus i zastanawiałem się, czy istnieje sposób, aby zadziałało to z pry-rescue.

Answer 1

Zastosowanie pry-rescue, to duchowy następca Plymouth

Z Readme:

Jeśli używasz rspec lub respec można otworzyć sesję podważyć na każdej awarii testowej używając RSpec ratunkowego lub ratunkowych 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

Możesz użyć do tego celu plymouth gem https://github.com/banister/plymouth. Używa jednak pry, ale (lepiej) alternatywy dla irb.

HTH

Answer 3

Trzeba złapać ExpectationNotMatched wyjątek gdy jest on budowany. Dołącz następujący kod do pomocników gdzieś i RSpec zatrzyma się podczas konstruowania wyjątku. Będzie to kilka poziomów głęboko w matcherach, więc w debugerze powiedz "gdzie", potem "do 5" lub "do góry 6", a znajdziesz się w instancji instance_exec twojego bloku. Debugger nie pokazuje poprawnie kodu w wersji, której używam, ale możesz "up" jeszcze raz i przejść do kodu działającego w tym samym kontekście, w którym twój test jest oceniany, dzięki czemu możesz sprawdzić zmienne instancji (ale nie wydaje się, że zmienne lokalne.

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 4

Możesz spróbować hammertime. Zostanie zatrzymany i pojawi się monit o przejście do interaktywnej sesji debugowania za każdym razem, gdy zostanie zgłoszony wyjątek.

Answer 5

Nie dostaniesz dostęp do zmiennych lokalnych (łatwo) bez debugger bycia w zakresie bloku, jednak RSpec oferuje wokół haków którego możemy to zrobić:

config.around(:each) do |example| 
    result = example.run 
    debugger if result.is_a?(Exception) 
    puts "Debugging enabled" 
end 

wtedy mieć dostęp do @ivars i subject/let(:var) zawartość w tym miejscu.

Answer 6

Lubię @ rozwiązania Jon-Rowe (potrzebne żadne dodatkowe klejnotów) z lekkim EDIT: I naprawdę nie dbają o innych błędach Aż RSpec::Expectations::ExpectationNotMetError.

config.around(:each) do |example| 
    example.run.tap do |result| 
     debugger if result.is_a?(RSpec::Expectations::ExpectationNotMetError) 
    end 
    end