Ruby on Rails
Debug

Debugging Rails Application

Per poter eseguire il debug di un'applicazione è molto importante comprendere il flusso della logica e dei dati di un'applicazione. Aiuta a risolvere bug logici e aggiunge valore all'esperienza di programmazione e alla qualità del codice. Due gemme popolari per il debugging sono debugger (per ruby ​​1.9.2 e 1.9.3) e byebug (per ruby> = 2.x).

Per il debug di file .rb , attenersi alla seguente procedura:

1. Aggiungi debugger o byebug al gruppo di development di Gemfile
2. Esegui bundle install
3. Aggiungi debugger o byebug come breakpoint
4. Esegui il codice o fai richiesta
5. Vedere il registro del server delle guide interrotto nel punto di interruzione specificato
6. A questo punto puoi utilizzare il tuo terminale server proprio come la rails console e controllare i valori di variabile e params
7. Per passare all'istruzione successiva, digitare next e premere enter
8. Per uscire da digitare c e premere enter

Se si desidera eseguire il debug .html.erb file .html.erb , il punto di interruzione verrà aggiunto come <% debugger %>

Debugging nel tuo IDE

Ogni buon IDE fornisce una GUI per il debugging interattivo di applicazioni Ruby (e quindi Rails) in cui è possibile aggiungere punti di interruzione, orologi, pausa automatica su eccezioni e consente di seguire l'esecuzione del codice anche passo dopo passo, riga per riga.

Ad esempio, dai uno sguardo alle migliori funzioni di debug di Ruby IDE e RubyMine sull'immagine

Debugging Ruby on Rails Quickly + Consigli per principianti

Il debugging sollevando eccezioni è molto più semplice dello strizzare gli occhi attraverso print istruzioni del registro di print e, per la maggior parte degli errori, è generalmente molto più veloce dell'apertura di un debugger irb come pry o byebug . Questi strumenti non dovrebbero essere il tuo primo passo.

Eseguire il debug di Ruby / Rails rapidamente:

1. Metodo veloce: Alza un Exception allora e .inspect suo risultato

Il modo più veloce per eseguire il debug del codice Ruby (in particolare Rails) consiste nel raise un'eccezione lungo il percorso di esecuzione del codice durante la chiamata a .inspect sul metodo o sull'oggetto (ad es. foo ):

raise foo.inspect

Nel codice precedente, raise innesca Exception che interrompe l'esecuzione del codice e restituisce un messaggio di errore che contiene convenientemente informazioni .inspect sull'oggetto / metodo (cioè foo ) sulla riga che si sta tentando di eseguire il debug.

Questa tecnica è utile per esaminare rapidamente un oggetto o un metodo ( ad esempio è nil ? ) E per confermare immediatamente se una linea di codice viene addirittura eseguita in un dato contesto.

2. Fallback: usa un debugger IRB rubino come byebug o pry

Solo dopo aver ricevuto informazioni sullo stato del flusso di esecuzione dei codici, dovresti prendere in considerazione la possibilità di passare a un debugger di ruby ​​gem irb come pry o byebug cui è possibile approfondire lo stato degli oggetti all'interno del percorso di esecuzione.

Per utilizzare la gem di byebug per il debug in Rails:

1. Aggiungi gem 'byebug' all'interno del gruppo di sviluppo nel tuo Gemfile
2. Esegui bundle install
3. Quindi per utilizzare, inserire la frase byebug all'interno del percorso di esecuzione del codice che si desidera esaminare.

Questa variabile di byebug quando eseguita aprirà una sessione IRB ruby ​​del tuo codice, dandoti l'accesso diretto allo stato degli oggetti così come sono a quel punto nell'esecuzione del codice.

I debugger IRB come Byebug sono utili per analizzare in profondità lo stato del tuo codice durante l'esecuzione. Tuttavia, sono procedure che richiedono più tempo rispetto all'aumento degli errori, quindi nella maggior parte delle situazioni non dovrebbero essere il primo passo.

Consigli generali per principianti

Quando si tenta di eseguire il debug di un problema, un buon consiglio è sempre: leggere il messaggio di errore! @ # $ Errore (RTFM)

Ciò significa che la lettura dei messaggi di errore con attenzione e completamente prima di agire in modo da capire che cosa sta cercando di dirti. Quando esegui il debug, poni le seguenti domande mentali, in questo ordine , durante la lettura di un messaggio di errore:

1. Quale classe fa riferimento all'errore? (cioè ho la classe dell'oggetto corretta o il mio oggetto è nil ? )
2. Quale metodo fa riferimento l'errore? (cioè è il loro un tipo nel metodo, posso chiamare questo metodo su questo tipo / classe di oggetto? )
3. Infine, usando ciò che posso dedurre dalle mie ultime due domande, quali linee di codice dovrei investigare? (ricorda: l'ultima riga di codice nella traccia dello stack non è necessariamente dove si trova il problema).

Nella traccia dello stack prestate particolare attenzione alle righe di codice che provengono dal vostro progetto (es. Le righe che iniziano con app/... se state usando Rails). Il 99% delle volte il problema è con il tuo codice.

Per illustrare perché interpretare in questo ordine è importante ...

Ad esempio un messaggio di errore Ruby che confonde molti principianti:

Esegui codice che ad un certo punto viene eseguito come tale:

@foo = Foo.new

...

@foo.bar

e ottieni un errore che afferma:

undefined method "bar" for Nil:nilClass

I principianti vedono questo errore e pensano che il problema sia che la bar del metodo non è definita . Non è. In questo errore la parte reale che conta è:

for Nil:nilClass

for Nil:nilClass significa che @foo è Nil! @foo non è una variabile di istanza di Foo ! Hai un oggetto che è Nil . Quando vedi questo errore, è semplicemente rubino cercando di dirti che la bar del metodo non esiste per oggetti della classe Nil . (beh, perché stiamo cercando di usare un metodo per un oggetto della classe Foo not Nil ).

Sfortunatamente, a causa di come viene scritto questo errore ( undefined method "bar" for Nil:nilClass ) è facile essere indotti a pensare che questo errore abbia a che fare con la bar undefined . Quando non viene letto attentamente, questo errore induce i principianti a scavare erroneamente nei dettagli del metodo bar su Foo , mancando completamente la parte dell'errore che suggerisce che l'oggetto è della classe sbagliata (in questo caso: nil). È un errore che è facilmente evitato leggendo i messaggi di errore nella loro interezza.

Sommario:

Leggere sempre attentamente l' intero messaggio di errore prima di iniziare qualsiasi debug. Ciò significa: Controllare sempre il tipo di classe di un oggetto in un messaggio di errore, poi i suoi metodi, prima di iniziare sleuthing in qualsiasi stacktrace o riga di codice in cui si pensa l'errore può essere che si verificano. Quei 5 secondi possono farti risparmiare 5 ore di frustrazione.

tl; dr: Non strizzare gli occhi ai registri di stampa: alza invece le eccezioni. Evita buchi di coniglio leggendo gli errori attentamente prima di eseguire il debug.

Eseguire il debug dell'applicazione ruby-on-rails con leva

leva è uno strumento potente che può essere utilizzato per eseguire il debug di qualsiasi applicazione di rubino. Impostare un'applicazione ruby-on-rails con questa gemma è molto semplice e diretto.

Impostare

Per avviare il debug della tua applicazione con leva

• Aggiungi gem 'pry' al Gemfile dell'applicazione e raggruppalo

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

• Passare alla directory principale dell'applicazione sulla console del terminale ed eseguire l' bundle install . Sei pronto per iniziare a utilizzarlo ovunque nella tua applicazione.

Uso

L'uso di leva nella tua applicazione include solo binding.pry sui punti di interruzione che vuoi ispezionare durante il debug. È possibile aggiungere i breakpoint di binding.pry qualsiasi punto dell'applicazione che viene interpretato dall'interprete ruby ​​(qualsiasi app / controller, app / modelli, file app / view)

i) Debug di un controller

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

In questo esempio, il server delle guide si interrompe con una console di leva al punto di interruzione quando si tenta di visitare un routing della pagina per show azione su UsersController . È possibile esaminare l'oggetto params e rendere la query ActiveRecord sul modello User da quel punto di interruzione

ii) Debug di una vista

app / views / utenti / 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"

In questo esempio, il punto di interruzione si interrompe con la console di leva quando la pagina degli users/show è precompilata nel server di rotaie prima di inviarla al browser del client. Questo break-point consente di correggere la correttezza di @user.logged_in? quando si comporta male.

ii) Debug di un modello

app/models/user.rb

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

In questo esempio, il punto di interruzione può essere utilizzato per eseguire il debug del metodo di istanza del modello User full_name quando questo metodo viene chiamato da qualsiasi punto dell'applicazione.

In conclusione, la leva è un potente strumento di debug per l'applicazione rails con una semplice impostazione e linee guida di debug semplici. Fai un tentativo.