Krótsze wyjście powrotne RSpec dla niepowodzeń testowych

Question

Używam RSpec (najnowsza wersja, 2.12.2) do przetestowania małej klasy Ruby, nad którą pracuję. Mój problem polega na tym, że gdy test RSpec nie powiedzie się, wynik testu wydaje się niewiarygodnie dokładny i pokazuje ogromną listę komunikatów o błędach, prawie co wydaje się być pełnym śledzeniem. Oznacza to, że muszę przewinąć w górę, aby zobaczyć faktyczny komunikat o błędzie i górę śladu.

Domyślnie RSpec powinien to zrobić, ale wydaje mi się, że nie robi tego dla mnie. Na przykład, jeśli biegnę rspec spec/my_spec.rb:132 (wystarczy uruchomić jeden test, który jest na L132), otrzymuję ten wynik:

Failure/Error: @f.has_changed?("test").should be_true 
    expected: true value 
     got: false 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/fail_with.rb:33:in `fail_with' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/handler.rb:33:in `handle_matcher' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/syntax.rb:53:in `should' 
# /Users/JackFranklin/Dropbox/Sites/rubygems/filefixtures/spec/filefixtures_spec.rb:137:in `block (4 levels) in <top (required)>' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:114:in `instance_eval' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:114:in `block in run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:254:in `with_around_each_hooks' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example.rb:111:in `run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:388:in `block in run_examples' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:384:in `map' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:384:in `run_examples' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:369:in `run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `block in run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `map' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `block in run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `map' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/example_group.rb:370:in `run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:28:in `map' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:28:in `block in run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/reporter.rb:34:in `report' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/command_line.rb:25:in `run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/runner.rb:80:in `run' 
# /Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-core-2.12.2/lib/rspec/core/runner.rb:17:in `block in autorun' 

który, jak widać, jest absolutnie ogromny. Nie mam żadnych plików konfiguracyjnych RSpec, które mogłyby zmienić konfigurację przekazaną do RSpec.

Czy ktoś to widział wcześniej? Próbowałem googlować, ale wyszukiwania były bezowocne.

Edit: I wtedy ustawić config, aby upewnić się, że jest ono zastosowanie domyślnego czyszczenie backtrace:

RSpec.configure do |config| 
    # RSpec automatically cleans stuff out of backtraces; 
    # sometimes this is annoying when trying to debug something e.g. a gem 
    config.backtrace_clean_patterns = [ 
    /\/lib\d*\/ruby\//, 
    /bin\//, 
    /gems/, 
    /spec\/spec_helper\.rb/, 
    /lib\/rspec\/(core|expectations|matchers|mocks)/ 
    ] 
end 

Ale to nie robi różnicy. Patrząc na dane wyjściowe, powinno się odfiltrować większość z nich, ale wygląda na to, że konfiguracja nie jest stosowana?

Edycja ponownie:

W moim config, mogę nawet biegać cleaned_from_backtrace?(line) aby sprawdzić, czy linia powinna być oczyszczona. Ten wraca true:

config.cleaned_from_backtrace?("/Users/JackFranklin/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/rspec-expectations-2.12.1/lib/rspec/expectations/fail_with.rb:33:in `fail_with'") 

Ale rzeczywista produkcja w terminalu pozostaje taka sama!

Edit 3:

Używam RSpec z poleceniem rspec, i nic więcej. Projektu .rspec plik zawiera:

--color 
--format progress 

I nie ma ~/.rspec plik albo które mogłyby być stosowanie ustawienia.

Answer 1

Po krótkiej rozmowie z RSpec folk on Github udało mi się uporać z problemem.

Problem polega na tym, że domyślnie RSpec usuwa linie z śledzenia, które pasują do Regex/gems /. Mój projekt został umieszczony w folderze o numerze gems w nazwie: ~/Dropbox/rubygems/myproject, dlatego usunięto wszystkie wiersze śledzenia wstecznego, a kiedy to nastąpi, RSpec rozsądnie pokazuje cały ślad śledzenia wstecznego.

To wyjaśnia zachowanie, które widziałem.

To zawsze coś głupiego. Mam nadzieję, że jeśli ktoś to zrobi, być może ta odpowiedź uratuje ich trochę czasu.

Answer 2

Wygląda na to, że korzystasz z protokołu RSpec z -b, aby uzyskać pełny ślad śledzenia. Zazwyczaj protokół RSpec nie będzie pokazywał własnego wewnętrznego śledzenia wstecznego, nawet wtedy, gdy test zakończy się niepowodzeniem (tzn. Wygeneruje wyjątek, a nie tylko niepowodzenie potwierdzenia). Jeśli nie uruchamiasz go jawnie pod numerem -b lub --backtrace, sprawdź i upewnij się, że nie masz tego zestawu w pliku konfiguracyjnym .rspec lub że IDE lub cokolwiek go nie przekazuje.

Answer 3

Zgodnie z tym, co powiedział Jim, dostępna jest opcja -b lub --backtrace, która umożliwi uzyskanie pełnego śledzenia wstecznego. Pamiętaj, że to nie tylko plik .rspec może go wyzwalać; jest też ~/.rspec (dla preferowanych opcji dewelopera).

Inną rzeczą, o której należy pamiętać, jest to, że formater może wypluć dowolną część śledzenia wstecznego, który chce. Formatery przedstawiają prosty sposób, w jaki dowolny formater stron trzecich może respektować konfigurację filtrowania wstecznego, ale jeśli używasz zewnętrznego formatera, nie ma gwarancji, że używa go prawidłowo. Czy używasz jednego z wbudowanych formaterów rspec?

Wreszcie, jeśli to nie jest jedna z tych rzeczy, to nie mam pomysłów. Musiałbym mieć przykład, na którym można grać, by odpowiedzieć na twoje pytanie. Czy możesz wymyślić powtarzalny przykład (w istocie, miejmy nadzieję)? Staram się regularnie spotykać w kanale rspec na irc.freenode.net, więc może złapiesz mnie tam i możemy rozwiązać problem w ten sposób.

Answer 4

Od wersji 3.4.0/2015-11-11 możliwe jest filtrowanie ślad za opcją:

RSpec.configure do |config| 
    config.filter_rails_from_backtrace! 
end