Ruby on Rails
デバッグ

CSS HTML JavaScript jQuery MongoDB MySQL postgresql Ruby Language SQL twitter-bootstrap
サーチ…


Railsアプリケーションのデバッグ

アプリケーションのロジックとデータの流れを理解するには、アプリケーションをデバッグできることが非常に重要です。論理的なバグを解決するのに役立ち、プログラミングの経験とコードの品質に価値をもたらします。 2つのデバッグ用の宝石として、 デバッガ （ruby 1.9.2と1.9.3）とbyebug （ruby> = 2.x）があります。

.rbファイルをデバッグするには、次の手順を実行します。

  1. debuggerまたはbyebugをbyebugのdevelopmentグループにGemfile
  2. bundle install実行bundle install
  3. debuggerまたはbyebugをブレークポイントとして追加する
  4. コードを実行するか、リクエストする
  5. 指定されたブレークポイントで停止したレール・サーバー・ログを参照してください
  6. この時点で、あなたはサーバ端末をrails consoleように使い、変数とパラメータの値をチェックすることができます
  7. 次の命令に移動するには、「 nextとenter nextを押しenter
  8. タイプcを押してenter cを押す場合

.html.erbファイルをデバッグ.html.erb場合、ブレークポイントは<% debugger %>として追加され<% debugger %>

IDEでのデバッグ

優れたIDEはすべて、ブレークポイント、時計、例外時に自動的に一時停止するRuby（およびRails）アプリケーションをインタラクティブにデバッグするためのGUIを提供しています。

たとえば、Ruby IDEの最良のRubyMineのデバッグ機能の1つ

ここに画像の説明を入力

Ruby on Railsを素早くデバッグする+初心者のアドバイス

例外を上げることにより、デバッグはを通じて細めよりもはるかに容易であるprintログステートメント、およびほとんどのバグのために、その一般的にはるかに高速のようなIRBデバッガ開くよりもpryまたはbyebug 。これらのツールはあなたの最初のステップであってはなりません。

Ruby / Railsをすばやくデバッグする：

1.高速メソッド： Exceptionを.inspectせ、その結果を.inspectする

Ruby（特にRails）コードをデバッグする最も速い方法は、メソッドやオブジェクト（例： foo ）で.inspectを呼び出しながら、コードの実行パスに沿って例外を発生さraiseです。 

raise foo.inspect

上記のコードでraise は、コードの実行を停止するExceptionをトリガし、デバッグしようとしている行のオブジェクト/メソッド（つまりfoo ）に関する.inspect情報を便利に含むエラーメッセージを返します。

このテクニックは、オブジェクトやメソッドを素早く調べるのに便利です（ 例えば、 nilはありnilんか？ ）、また、特定のコンテキスト内でコードの行がまったく実行されているかどうかをすぐに確認するのに便利です。

2.フォールバック：ようルビーIRBデバッガを使用しbyebugまたはpry

あなたのコードの実行フローの状態についての情報を持っていた後にのみ、あなたのようなルビーの宝石IRBデバッガへの移行を検討してくださいpryやbyebugあなたの実行パス内のオブジェクトの状態にさらに深く掘り下げることができます。

byebug gemをRailsでのデバッグに使用するには：

  1. 追加gem 'byebug'ごGemfileに開発グループ内
  2. bundle install実行bundle install
  3. 使用するには、調べたいコードの実行パスの中にbyebugというフレーズを挿入します。

このbyebug変数を実行すると、コードのルビIRBセッションが開き、コードの実行中にその時点のオブジェクトの状態に直接アクセスできるようになります。

ByebugのようなIRBデバッガは、実行されるコードの状態を深く分析するのに便利です。しかし、エラーを発生させるのに比べて手続きは時間がかかりますので、ほとんどの状況では最初のステップではありません。

初心者のアドバイス

問題をデバッグしようとしているときは、常にアドバイスをしてください： ！@＃$ ingエラーメッセージ（RTFM）

つまり、演技の前にエラーメッセージを慎重かつ完全に読み取って、 何を伝えようとしているのかを理解することを意味します。デバッグするときは、エラーメッセージを読むときに、次の精神的な質問をこの順番で尋ねます。

  1. どのクラスがエラーを参照していますか？ （つまり、私は正しいオブジェクトクラスを持っているのですか？またはオブジェクトがnilですか？ ）
  2. エラーはどのような方法で参照されますか？ （つまり、メソッドの型です;この型/オブジェクトのクラスでこのメソッドを呼び出せますか？ ）
  3. 最後に、最後の2つの質問から推測できるものを使って、どのようなコード行を調べるべきですか？ （覚えておいてください：スタックトレース内の最後のコード行は、必ずしも問題が存在する場所ではありません。）

スタックトレースでは、あなたのプロジェクトから来るコードの行に注意を払うべきapp/... （例えば、Railsを使っているなら、 app/...始まる行）。自分のコードで問題が発生している時間の99％。

この順序で解釈することが重要な理由を説明するために ...

たとえば、多くの初心者を混乱させるRubyエラーメッセージ：

ある時点でそのようなコードを実行します： 

@foo = Foo.new

...

@foo.bar

次のようなエラーが表示されます。

undefined method "bar" for Nil:nilClass

初心者はこのエラーを見て、メソッドbarが定義されていないという問題があると考えます。 そうではありません。このエラーでは、重要な部分は次のとおりです。

for Nil:nilClass

for Nil:nilClassは@fooがNilであることを意味します。 @fooはFooインスタンス変数ではありません！あなたはNilオブジェクトを持っています。このエラーが表示されたときは、単純にルビがクラスNilオブジェクトに対してメソッドbarが存在しないことを伝えようとしています。 （私たちがクラスFooオブジェクトに対してNilはないメソッドを使用しようとしているからです。

残念ながら、このエラーがどのように記述されているのか（ undefined method "bar" for Nil:nilClass ）、このエラーは、 barがundefinedと考える必要がありbar 。注意深く読まないと、このエラーは初心者が誤ってFooのbarメソッドの詳細を掘り下げ、オブジェクトが間違ったクラス（この場合はnil）であることを示唆するエラーの一部を完全に欠いてしまいます。エラーメッセージ全体を読むことで簡単に回避できる間違いです。

概要：

デバッギングを開始する前に、必ずエラーメッセージ全体を注意深くお読みください 。それは意味：あなたは、エラーが発生するかもしれないと思うのコードのいずれかのスタックトレースまたはラインにsleuthing開始する前に 、必ず、そのメソッドその後、 最初のエラーメッセージでオブジェクトのクラス型を確認してください。それらの5秒はあなたに5時間の欲求不満を救うことができます。

tl; dr：印刷ログを調べないでください。代わりに例外を発生させてください。デバッグする前にエラーを注意深く読んで、ウサギの穴を避けてください。

pryを使ってruby-on-railsアプリケーションをデバッグする

pryは、Rubyアプリケーションをデバッグするために使用できる強力なツールです。この宝石を使ってRuby-on-Railsアプリケーションを設定するのは、とても簡単で簡単です。

セットアップ

pryでアプリケーションのデバッグを開始するには

  • アプリケーションのGemfileにgem 'pry' Gemfile gem 'pry'を追加してバンドルします
group :development, :test do
  gem 'pry'
end
  • ターミナルコンソールでアプリケーションのルートディレクトリに移動し、 bundle installます。アプリケーションのどこにでも使い始めることができます。

つかいます

アプリケーションでpryを使用すると、デバッグ中に検査したいブレークポイントにbinding.pryを含めるだけです。 binding.pryブレークポイントは、Rubyインタープリタ（app / controllers、app / models、app / viewsファイル）によって解釈されるアプリケーションのどこにでも追加binding.pryます。

i）コントローラのデバッグ

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

この例では、ページルーティングにアクセスしてUsersControllerアクションをshowしようとすると、レールサーバーがブレークポイントでコンソールを使用して一時停止します。 paramsオブジェクトを調べて、そのブレークポイントからUserモデルのActiveRecordクエリを作成できます

ii）ビューのデバッグ

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"

この例では、 users/showページがクライアントのブラウザに返送される前に、railsサーバであらかじめコンパイルされているとき、pryコンソールでブレークポイントが一時停止します。このブレークポイントは、 @user.logged_in?正しさをデバッグできます@user.logged_in?それが間違っているとき。

ii）モデルのデバッグ

app/models/user.rb

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

この例では、このメソッドがアプリケーションのどこからでも呼び出されたときに、ブレークポイントを使用してUserモデルのインスタンスメソッドfull_nameをデバッグすることができます。

結論として、pryは簡単な設定と簡単なデバッグガイドラインを備えたレールアプリケーション用の強力なデバッグツールです。これを試してみてください。



Modified text is an extract of the original Stack Overflow Documentation
ライセンスを受けた CC BY-SA 3.0
所属していない Stack Overflow