You can see also http://blog.s21g.com/articles/212, the article written about the same theme for comparison, if you are familiar to Japanese.

1. p/pp

This is a very popular method used not only in Rails but also in other debugging. In Rails this method should be used on web server which is in the states of foreground process.

   1   $ ./script/server

If you are familiar with p/pp, it should be simple and easy.

2. logger.debug

For logger.debug, the following example will explain fully.

   1  logger.debug "something interesting information"

Calling logger.debug, you can create a log file of log/$RAILS_ENV.log such as log/development.log.

By configuring the output file to:

   1  $ tail -f log/development.log

you can check the debug output log in the same manner as in p/pp debugging. Furthermore, as the result is output in a log-file format, you can refer it later on.

3. script/console

script/console comes in handy when you check the DB contents during the operation. Executing "script/console" command, irb launches after confirming Rails environment. You can change DB as you like by using ActiveRecord, such as find, create and destroy_all.This is very tactful feature.

4. script/breakpointer

As previously described, although script/console comes in very handy and tactful, it can not check session status during the action. In that case, you can use "script/breakpointer" for it.

   1  $ ./script/breakpointer

Please make sure to launch a breakpointer initially. Then locate a "breakpoint" to the position where you want to check the status.

   1  class FooController < ApplicationController
   2    def bar
   3      # something
   4      breakpoint
   5      # something
   6    end

Then you execute bar action through brower access and check and manupulate the necessary information after the launch of irb at the set breakpointer.

5. better rails debugger

script/breakpointer is very useful but it has a weak point as it cannot operate step execution. We understand you rarely experience the need for step execution, however, it's better to have a method than nothing. The ruby-debug Gem, informed by yugui in the last Rails meeting, will meet the need. First of all, make sure to install ruby-debug in advance.

   1  # gem install ruby-debug

Then, add a breakpoint.

   1  class FooController < ApplicationController
   2    def bar
   3      # something
   4      debugger
   5      # something
   6    end

After launching Web server such as Webrick or Mongrel on foreground, which is used in p/pp debugging, you make an access to execute targeted code through the browser. Then something similer to debug.rb launches in Web server process. Now you can start debuggin in the same manner as you do with general ruby script.

6. test/autotest

In Ruby on Rails, test framework is ready to use by default. Generally, specification is designed after writing a test code in test operation development. However, you can write a test code for verification of desired behavior and also utilize it for debugging. It takes time to operate every test by using "rake" command, I recommend to use autotest in ZenTest.This autotest operates only related tests for modified files, and can provide quicker response than using "rake" command. If you use a redgreen as a combination, the smooth operation will please you while debuggin.

7. tail -f log/development.log&; autotest

Lastly, let me intriduce my current method.I launch a separate terminal other than for development, and operate following command in RAILS_ROOT.

   1  $ tail -f log/development.log&; autotest

This arrangement enables to display the autotest output in editing program and test code and the logger output when there is an access from the browser. Basically, those two runs asynchronously, you can fully use one terminal.

posted by Png genki on Fri 4 Jan 2008 at 05:17

Comments:

or Preview
Social Bookmarks
  • Delicious
  • B_entry297
  • Clip_16_12_w
Services from s21g
twpro(ツイプロ)
Twitterプロフィールを快適検索
地価2009
土地の値段を調べてみよう
MyRestaurant
自分だけのレストラン手帳
Formula
ブログに数式を埋め込める数式コミュニティ