views:

88

answers:

1

I've inherited a large pile of Ruby code that's, frankly, close to impossible to understand for a mortal like myself. It's actually Rspec unit test code, but the structure is "highly unusual" to put it nicely.

What I'd like to be able to do is run the code, and have the following information logged somewhere:

  • every method that gets invoked, including the name of the class that defines the method, and the filename where the invoked method has been defined (yep, we've got the same class/method defined in multiple different files, and it's tough to know which is being invoked)
  • (optionally) the parameters passed to each method invoked

With that, I could start trying to refactor it. Without it, it's going to be a very difficult task to get it straightened out, due to the size of the code base (20k+ unit test cases).

I can't afford to go in and perform wholesale edits to the code being run, because it breaks when you even use harsh language around it (i.e. frequently). Instead, I need to be able to instrument the code in its existing state, or with minimal changes to what exists now.

Is there a way of logging this level of detail without making wholesale changes to the code base? I've had a look at the Ruby profiler to see if it could help, and it probably could; I'm curious if there's a better way (particularly logging the filename containing the invoked method).

Thanks in advance

+8  A: 

This is definitely possible -- in fact, there's even a method for it! Just add this somewhere in your code before the point that you want to start logging things:

set_trace_func proc { |event, file, line, id, binding, classname|
  printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, classname
}

The secret sauce you want comes from Kernel#set_trace_func, as noted above:

  • set_trace_func(proc) => proc
  • set_trace_func(nil) => nil

Establishes proc as the handler for tracing, or disables tracing if the parameter is nil. proc takes up to six parameters: an event name, a filename, a line number, an object id, a binding, and the name of a class. proc is invoked whenever an event occurs. Events are: c-call (call a C-language routine), c-return (return from a C-language routine), call (call a Ruby method), class (start a class or module definition), end (finish a class or module definition), line (execute code on a new line), raise (raise an exception), and return (return from a Ruby method). Tracing is disabled within the context of proc.

Here's a handy example:

class Test
  def test
    a = 1
    b = 2
  end
end

set_trace_func proc { |event, file, line, id, binding, classname|
  printf "%8s %s:%-2d %10s %8s\n", event, file, line, id, classname
}

t = Test.new
t.test

(Note: don't try this in irb unless you want a huge scrolling screen of text.) The resulting output is:

    line test.rb:11               false
  c-call test.rb:11        new    Class
  c-call test.rb:11 initialize   Object
c-return test.rb:11 initialize   Object
c-return test.rb:11        new    Class
    line test.rb:12               false
    call test.rb:2        test     Test
    line test.rb:3        test     Test
    line test.rb:4        test     Test
  return test.rb:4        test     Test

You can play around with the formatting string above to get just the results you want to log (for example, it sounds like you're only interested in call events). Hope that helps, and good luck with sorting through all those unit tests!

John Feminella
Wow - that's ... exactly what I was hoping for. Thanks John!
monch1962
No problemo. Ruby turns out to be quite handy with this sort of Swiss-Army-knife stuff.
John Feminella