Ruby on Rails
Debugowanie

Aplikacja do debugowania w Railsach

Aby móc debugować aplikację, bardzo ważne jest zrozumienie przepływu logiki i danych aplikacji. Pomaga w rozwiązywaniu problemów logicznych i zwiększa wartość programowania oraz jakość kodu. Dwa popularne klejnoty do debugowania to debugger (dla Ruby 1.9.2 i 1.9.3) i byebug (dla Ruby> = 2.x).

W celu debugowania plików .rb wykonaj następujące kroki:

1. Dodaj debugger lub byebug do grupy development Gemfile
2. Uruchom bundle install
3. Dodaj debugger lub byebug jako punkt przerwania
4. Uruchom kod lub złóż wniosek
5. Zobacz dziennik serwera szyn zatrzymany w określonym punkcie przerwania
6. W tym momencie możesz używać terminala serwera, podobnie jak rails console i sprawdzać wartości zmiennych i parametrów
7. Aby przejść do następnej instrukcji, wpisz next i naciśnij enter
8. Aby wyjść, wpisz c i naciśnij enter

Jeśli chcesz debugować pliki .html.erb , punkt przerwania zostanie dodany jako <% debugger %>

Debugowanie twojego IDE

Każde dobre IDE zapewnia GUI do interaktywnego debugowania aplikacji Ruby (a tym samym Railsów), w których można dodawać punkty przerwania, zegarki, automatyczne wstrzymywanie w wyjątkach i pozwala śledzić wykonanie kodu nawet krok po kroku, linia po linii.

Na przykład spójrz na jedną z najlepszych Ruby IDE, funkcje debugowania RubyMine na zdjęciu

Szybkie debugowanie Ruby on Rails + Porady dla początkujących

Debugowania poprzez podnoszenie wyjątków jest znacznie łatwiejsze niż mrużąc poprzez print sprawozdań z bali, a dla większości błędów, jego na ogół znacznie szybciej niż otwarcie IRB debugger jak pry lub byebug . Te narzędzia nie powinny być twoim pierwszym krokiem.

Szybkie debugowanie Ruby / Rails:

1. Szybka metoda: następnie podnieś Exception i .inspect jego wynik

Najszybszym sposobem debugowania kodu Ruby (zwłaszcza Railsowego) jest raise wyjątku wzdłuż ścieżki wykonania kodu podczas wywoływania metody .inspect w metodzie lub obiekcie (np. foo ):

raise foo.inspect

W powyższym kodzie raise wyzwala Exception który zatrzymuje wykonywanie kodu i zwraca komunikat o błędzie, który dogodnie zawiera .inspect informacje o obiekcie / metodzie (tj. foo ) w linii, którą próbujesz debugować.

Ta technika jest przydatna do szybkiego badania obiektu lub metody ( np. Czy to nil ? ) I do natychmiastowego potwierdzenia, czy wiersz kodu w ogóle jest wykonywany w danym kontekście.

2. Awaryjne: Użyj ruby debuggera IRB, takiego jak byebug lub pry

Dopiero po uzyskaniu informacji o stanie przepływu kodów należy rozważyć przejście do debugera irb gem ruby, takiego jak pry lub byebug którym można głębiej zagłębić się w stan obiektów na ścieżce wykonywania.

Aby użyć klejnotu byebug do debugowania w Railsach:

1. Dodaj gem 'byebug' do grupy rozwoju w swoim pliku Gem
2. Uruchom bundle install
3. Następnie, aby użyć, wstaw wyrażenie byebug w ścieżkę wykonania kodu, który chcesz sprawdzić.

Ta zmienna byebug po uruchomieniu otworzy rubinową sesję IRB twojego kodu, dając ci bezpośredni dostęp do stanu obiektów, jakie są w tym momencie w wykonywaniu kodu.

Debugery IRB, takie jak Byebug, są przydatne do dogłębnej analizy stanu wykonywanego kodu. Są to jednak bardziej czasochłonne procedury w porównaniu do zgłaszania błędów, więc w większości sytuacji nie powinny być Twoim pierwszym krokiem.

Ogólne porady dla początkujących

Gdy próbujesz debugować problem, dobrą radą jest zawsze: Przeczytaj komunikat o błędzie! @ # $ Ing o błędzie (RTFM)

Oznacza to uważne i całkowite przeczytanie komunikatów o błędach przed podjęciem działań, aby zrozumieć, co próbuje ci powiedzieć. Podczas debugowania podczas czytania komunikatu o błędzie zadaj następujące pytania mentalne, w tej kolejności :

1. Do jakiej klasy odnosi się błąd? (tj. czy mam poprawną klasę obiektu lub czy mój obiekt jest nil ? )
2. Do jakiej metody odnosi się błąd? (tzn. czy jest to typ w metodzie; czy mogę wywołać tę metodę dla tego typu / klasy obiektu? )
3. Wreszcie, korzystając z tego, co mogę wywnioskować z dwóch ostatnich pytań, jakie wiersze kodu powinienem zbadać? (pamiętaj: ostatni wiersz kodu w stosie niekoniecznie musi znajdować się w miejscu, w którym leży problem).

Podczas śledzenia stosu zwróć szczególną uwagę na wiersze kodu pochodzące z twojego projektu (np. Wiersze zaczynające się od app/... jeśli używasz Railsów). W 99% przypadków problem dotyczy Twojego kodu.

Aby zilustrować, dlaczego tłumaczenie w tej kolejności jest ważne ...

Np. Komunikat o błędzie Ruby, który dezorientuje wielu początkujących:

Wykonujesz kod, który w pewnym momencie wykonuje jako taki:

@foo = Foo.new

...

@foo.bar

i pojawia się błąd o treści:

undefined method "bar" for Nil:nilClass

Początkujący widzą ten błąd i myślą, że problem polega na tym, że bar metody jest niezdefiniowany . To nie jest. W tym błędzie istotną częścią jest:

for Nil:nilClass

for Nil:nilClass oznacza, że @foo ma wartość Nil! @foo nie jest zmienną instancji Foo ! Masz obiekt, który jest Nil . Gdy zobaczysz ten błąd, po prostu ruby próbuje powiedzieć ci, że bar metod nie istnieje dla obiektów klasy Nil . (no cóż, skoro próbujemy użyć metody dla obiektu klasy Foo nie Nil ).

Niestety, ze względu na sposób zapisu tego błędu ( undefined method "bar" for Nil:nilClass ) łatwo jest oszukać, że błąd ten ma związek z undefined bar . Jeśli nie zostanie dokładnie przeczytany, ten błąd powoduje, że początkujący omyłkowo zagłębiają się w szczegóły metody bar na Foo , całkowicie pomijając tę część błędu, która sugeruje, że obiekt jest niewłaściwej klasy (w tym przypadku: zero). To błąd, którego łatwo uniknąć, czytając w całości komunikaty o błędach.

Streszczenie:

Zawsze uważnie przeczytaj cały komunikat o błędzie przed rozpoczęciem debugowania. Oznacza to, że: Zawsze sprawdzić typ klasy obiektu w komunikacie o błędzie, potem swoje metody, przed rozpoczęciem sleuthing do dowolnego stacktrace lub linii kodu, w którym myślisz, że błąd może mieć miejsce. Te 5 sekund pozwala zaoszczędzić 5 godzin frustracji.

tl; dr: Nie zezuj na dzienniki wydruku: zamiast tego zgłaszaj wyjątki. Unikaj króliczych dziur, uważnie czytając błędy przed debugowaniem.

Debugowanie aplikacji ruby-on-rails za pomocą narzędzia podważającego

pry to potężne narzędzie, którego można użyć do debugowania dowolnej aplikacji ruby. Konfigurowanie aplikacji rubin na szynach z tym klejnotem jest bardzo łatwe i proste.

Ustawiać

Aby rozpocząć debugowanie aplikacji za pomocą narzędzia pry

• Dodaj gem 'pry' do Gemfile aplikacji i Gemfile go

group :development, :test do
  gem 'pry'
end

• Przejdź do katalogu głównego aplikacji na konsoli terminali i uruchom bundle install . Wszystko gotowe do użycia go w dowolnym miejscu aplikacji.

Posługiwać się

Używanie narzędzia pry w Twojej aplikacji polega tylko na włączeniu binding.pry w binding.pry przerwania, które chcesz sprawdzić podczas debugowania. Możesz dodać punkty przerwania binding.pry w dowolnym miejscu aplikacji, które jest interpretowane przez interpreter ruby (dowolna aplikacja / kontrolery, aplikacja / modele, pliki aplikacji / widoków)

i) Debugowanie kontrolera

app / controllers / users_controller.rb

class UsersController < ApplicationController
  def show
    use_id = params[:id]
    // breakpoint to inspect if the action is receiving param as expected
    binding.pry
    @user = User.find(user_id)
    respond_to do |format|
      format.html
    end
  end
end

W tym przykładzie serwer railsowy zatrzymuje się z podważoną konsolą w punkcie przerwania, gdy próbujesz odwiedzić routing strony, aby show akcję na UsersController . Możesz sprawdzić obiekt params i wykonać zapytanie ActiveRecord na modelu User od tego punktu przerwania

ii) Debugowanie widoku

app / views / users / show.html.haml

%table
  %tbody
    %tr
      %td ID
      %td= @user.id
    %tr
      %td email
      %td= @user.email
    %tr
      %td logged in ?          
      %td
        - binding.pry
        - if @user.logged_in?
          %p= "Logged in"
        - else
          %p= "Logged out"

W tym przykładzie punkt przerwania jest wstrzymywany za pomocą konsoli podważania, gdy strona users/show jest wstępnie skompilowana na serwerze szyn przed wysłaniem jej z powrotem do przeglądarki klienta. Ten punkt przerwania pozwala debugować poprawność @user.logged_in? kiedy źle się zachowuje.

ii) Debugowanie modelu

app/models/user.rb

class User < ActiveRecord::Base    
  def full_name
    binding.pry
    "#{self.first_name} #{self.last_name}"
  end      
end

W tym przykładzie, break-point może być używany do debugowania User modelu instancji metody full_name gdy ta metoda jest wywoływana z dowolnego miejsca w aplikacji.

Podsumowując, pry jest potężnym narzędziem do debugowania aplikacji do szyn z łatwą konfiguracją i prostą wytyczną debugowania. Spróbuj tego.