Strategy Recommendations for Advanced Rails Debugging?

Question

I've been coding in Ruby / Rails for almost 9 months now, having spent the years before in Python.

While I really enjoy Rails, there is one area where I get frustrated a lot: chasing stubborn bugs. In other languages, I can almost always track difficulties without any particular problems, but when I hit the rails of a wall, I usually hit a wall. I suppose I ask: what strategies do advanced rail users use to track more stubborn errors?

At the moment, my approach is usually:

• Examine the stack trace (the simplest errors are resolved here)

• Run debugger / pry / console and check the environment, go through each step if necessary

• Google

• Reporting stack overflow problems / github

• Agitate and / or swear profusely

If any advanced rails would share their strategy to pursue more stubborn mistakes, I would be very grateful. In short, what to do when the trace / debugger does not offer any hints?

Answer 1

Having been with Rails in just 5 years, I do not consider myself an advanced Railser, but, nevertheless, I gladly shared my knowledge. :-)

The main thing when dealing with anyone (with the exception of some very, very trivial ones) is to write a test for this error .

Several times it happened that I solved the error at this stage - for example, when the error was associated with a reload of the automatic class, which is active in development and disabled in test mode.

Then I usually place some logger.debug with lots of inspect and caller(0).join("\n\t") . Then I study the log file very carefully.

Since "test.log" can have several hundred megabytes, I always forget to reset it to zero before starting the test. In addition, I usually run only one test method at a time, because the output would be unreadable otherwise.

I do not use a dedicated debugger. In some old version of ruby, the debugger stops working, I learned how to live without it and never looked back.

---

A few useful utilities that may be useful:

A function defined in my ~/.bashrc that allows me to call one test method (or group of methods):

 $ testuj test/unit/user_test.rb -n test_name_validations $ testuj test/unit/user_test.rb -n /_name_/ 

 function testuj () { if [ -n "${BUNDLE_GEMFILE}" ] then # This is a Rails3 project - it is run by `bundle exec` ruby -I"lib:test" " $@ " else # This is a Rails1 project. No bundler. ruby -e 'ARGV.each { |f| load f unless f =~ /^-/ ; break if f == "-n" }' " $@ " fi } 

And this method helps me with logging and checking the timing of certain steps:

 Object.module_eval do def czekpoint(note = nil) n = Time.now $czekpoint_previous ||= n $czekpoint_number ||= 0 $czekpoint_number += 1 t = n - $czekpoint_previous msg = "CZEKPOINT: %2d %8.6f %s %s" % [$czekpoint_number, t, caller.first.to_s.in_yellow, note.to_s.in_red] Rails.logger.debug msg # In older Rails it was RAILS_DEFAULT_LOGGER STDERR.puts msg $czekpoint_previous = n end end 

Answer 2

I personally believe that shooting at the rail console and manually stepping things over there helps to deal with the most "difficult to track" errors. However, recently I started using pry and added calls to "binding.pry" in the code that I want to debug. The trick seems to be to figure out where to place the binding.pry call. Invaluable code, as well as the complex test code that you inherited.