Ruby on Rails
felsökning

Debugging Rails-applikation

För att kunna felsöka en applikation är det mycket viktigt att förstå flödet av applikationens logik och data. Det hjälper till att lösa logiska buggar och tillför värde till programmeringsupplevelsen och kodkvaliteten. Två populära ädelstenar för felsökning är felsökare (för rubin 1.9.2 och 1.9.3) och bybug (för rubin> = 2.x).

Följ stegen för felsökning av .rb filer:

1. Lägg till debugger eller byebug till development för Gemfile
2. Kör bundle install
3. Lägg till debugger eller byebug som brytpunkt
4. Kör koden eller gör begäran
5. Se railserverloggen stoppad vid den angivna brytpunkten
6. På denna punkt kan du använda din serverterminal precis som rails console och kontrollera värdena på variabel och param
7. För att gå till nästa instruktion, skriv next och tryck på enter
8. För att gå ut typ c och tryck på enter

Om du vill felsöka .html.erb filer .html.erb till som <% debugger %>

Felsökning i din IDE

Varje bra IDE tillhandahåller ett GUI för interaktivt felsökning av Ruby-applikationer (och därmed Rails) där du kan lägga till brytpunkter, klockor, automatiskt pausa på undantag och låter dig följa kodutförandet även steg för steg, rad för rad.

Ta till exempel en av de bästa Ruby IDE: er, RubyMines felsökningsfunktioner på bilden

Debugging Ruby on Rails Quick + Nybörjarråd

Att felsöka genom att höja undantag är mycket enklare än att krysa igenom print , och för de flesta buggar är det i allmänhet mycket snabbare än att öppna upp en irb-felsökare som pry eller byebug . Dessa verktyg bör inte vara ditt första steg.

Debugging Ruby / Rails snabbt:

1. Snabbmetod: höja ett Exception då och .inspect resultatet

Det snabbaste sättet att felsöka Ruby-kod (särskilt Rails) är att raise ett undantag längs körningsvägen för din kod medan du ringer .inspect på metoden eller objektet (t.ex. foo ):

raise foo.inspect

I ovanstående kod, raise utlöser ett Exception som stoppar körningen av din kod och returnerar ett felmeddelande som bekvämt innehåller .inspect information om objektet / metoden (dvs. foo ) på den rad som du försöker felsöka.

Denna teknik är användbar för att snabbt undersöka ett objekt eller en metod ( t.ex. är det nil ? ) Och för att omedelbart bekräfta om en kodrad till och med körs alls inom ett givet sammanhang.

2. Fallback: Använd en rubin IRB- felsökare som byebug eller pry

Först efter att du har fått information om tillståndet för dina koder exekveringsflöde bör du överväga att flytta till en rubin gem irb debugger som pry eller byebug där du kan gå djupare in i tillståndet för objekt i din körningsväg.

byebug använder du byebug pärla för felsökning i Rails:

1. Lägg till gem 'byebug' i utvecklingsgruppen i din Gemfile
2. Kör bundle install
3. För att sedan använda, sätta in frasen byebug i körningsvägen för koden du vill undersöka.

Denna byebug variabel när den körs öppnar en rubin IRB-session av din kod, vilket ger dig direkt tillgång till objekttillståndet som de är vid den punkten i kodens körning.

IRB-debuggers som Byebug är användbara för att djupt analysera statusen för din kod när den körs. Men de är mer tidskrävande förfaranden jämfört med att ta upp fel, så i de flesta situationer borde de inte vara ditt första steg.

Allmän nybörjarråd

När du försöker felsöka ett problem är bra råd att alltid: Läs felmeddelandet @ @ $ $ (RTFM)

Det betyder att du läser felmeddelanden noggrant och fullständigt innan du agerar så att du förstår vad den försöker berätta för dig. När du felsöker, ställer du följande mentala frågor, i den här ordningen , när du läser ett felmeddelande:

1. Vilken klass hänvisar felet till? (dvs. har jag rätt objektklass eller är mitt objekt nil ? )
2. Vilken metod hänvisar felet till? (dvs. är deras en typ i metoden; kan jag kalla den här metoden på den här typen / objektklassen? )
3. Slutligen, med vad jag kan dra från mina två senaste frågor, vilka kodrader ska jag undersöka? (kom ihåg: den sista koden i stapelspåret är inte nödvändigtvis där problemet ligger.)

I stapelspåret ska du vara särskilt uppmärksam på koderader som kommer från ditt projekt (t.ex. rader som börjar med app/... om du använder Rails). 99% av tiden är problemet med din egen kod.

För att illustrera varför tolkning i denna ordning är viktig ...

Exempelvis ett Ruby-felmeddelande som förvirrar många nybörjare:

Du kör kod som vid någon tidpunkt körs som sådan:

@foo = Foo.new

...

@foo.bar

och du får ett fel som säger:

undefined method "bar" for Nil:nilClass

Nybörjare ser detta fel och tror att problemet är att bar är odefinierat . Det är inte. I det här felet är den verkliga delen som är viktig:

for Nil:nilClass

for Nil:nilClass betyder att @foo är @foo ! @foo är inte en Foo instansvariabel! Du har ett objekt som är Nil . När du ser detta fel är det bara rubin som försöker säga att bar inte finns för objekt i klassen Nil . (tja du! eftersom vi försöker använda en metod för ett objekt i klassen Foo inte Nil ).

På grund av hur detta fel skrivs ( undefined method "bar" for Nil:nilClass ) är det undefined method "bar" for Nil:nilClass lätt att luras till att tänka att detta fel har att göra med att bar är undefined . När detta fel inte läses noggrant får detta fel nybörjare att felaktigt gå in i detaljerna i bar på Foo , helt saknar den delen av felet som antyder att objektet är i fel klass (i detta fall: noll). Det är ett misstag som lätt undviks genom att läsa felmeddelanden i sin helhet.

Sammanfattning:

Läs alltid noggrant hela felmeddelandet innan du börjar felsöka. Det betyder: Kontrollera alltid klassens typ av ett objekt i ett felmeddelande först , sedan dess metoder , innan du börjar sluta i någon stacktrace eller kodrad där du tror att felet kan förekomma. Dessa 5 sekunder kan spara dig 5 timmars frustration.

tl; dr: Kvisa inte vid tryckta loggar: höja undantag istället. Undvik kaninhål genom att läsa fel noggrant innan du felsöker.

Felsökning av ruby-on-rails-applikation med rov

pry är ett kraftfullt verktyg som kan användas för att felsöka alla rubinprogram. Det är väldigt enkelt och enkelt att ställa in en ruby-on-rails-applikation med denna pärla.

Uppstart

För att börja felsöka din ansökan med böja

• Lägg till gem 'pry' i applikationens Gemfile och bunt det

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

• Navigera till programmets rotkatalog på terminalkonsolen och kör bundle install . Du är redo att börja använda den var som helst i din applikation.

Använda sig av

Att använda brev i din ansökan inkluderar bara binding.pry på de brytpunkter du vill inspektera vid felsökning. Du kan lägga till binding.pry brytpunkter var som helst i din applikation som tolkas av rubin-tolk (valfri app / kontroller, app / modeller, app / visningsfiler)

i) Felsöka en kontroller

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

I det här exemplet pausas servern med en böja-konsol vid brytpunkten när du försöker besöka en sidruttning för att show åtgärder på UsersController . Du kan inspektera params objekt och göra Active fråga på User modell från den brytpunkt

ii) Felsöka en vy

app / views / användare / 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"

I det här exemplet pausar brytpunkten med pry-konsolen när users/show sidan är förkompilerad i railserveren innan den skickas tillbaka till klientens webbläsare. Den här brytpunkten gör det möjligt att felsöka riktigheten av @user.logged_in? när det inte fungerar.

ii) Felsöka en modell

app/models/user.rb

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

I detta exempel, kan brytpunkten användas för att felsöka User modellens instansmetod full_name när denna metod anropas från var som helst i programmet.

Sammanfattningsvis är pry ett kraftfullt felsökningsverktyg för rälsapplikationer med enkel installation och enkel riktning för felsökning. Prova detta.