From: nahi@... (NAKAMURA, Hiroshi)
Date: 2002-05-04T16:30:52+09:00
Subject: Re: set_trace_func and code coverage

Hi,

mrp@cre.canon.co.uk wrote in message news:<GvJ3vB.11H@cre.canon.co.uk>...
> ruby 1.6.6 
> 
> #!/usr/local/bin/ruby -w
> $lines = []
> set_trace_func( proc {|eventname, filename, lineno, objid, binding, classname|
> 				 $lines << lineno if ( eventname == "line") })
> 
> at_exit {  puts $lines.sort.uniq } 
> 
> ['foo','bar','baz'].each{|w|
>   puts w    # line 9
> }           # line 10
> 
> =====
> produces:
> $ ./cover.rb 
> foo
> bar
> baz
> 6
> 8
> 9
> $
> 
> and if   |w|   was on it's own line, that's not 'executed' either.
> 
> from a parsing point of view i can see that line 10 isn't _really_
> executable code, but from trying to use this as a code coverage tool,
> this is a bit of a pain, especially with lines containing many
> delimiters.
> 
> my question's are: 
> 	should lines containing just delimeters be included with the output 
> 	   shown above, or 

I hope it is included, but...
In current debug/trace API of ruby interpreter, return
event is raised from the last node of parsed tree.
You must do somewhat ad-hoc process to map source code
to parsed tree.

Besides this, current debug/trace API is rather poor at
iteration block such as your example.  No call/return
event is raised from the block.  Matz might add these
event if we can define spec. explicitly.

> 	is thinking about code-coverage a bit out of date with dynamic 
>        languages?

I don't think so.  Unit test must be with coverage tool, I think.

> or is there a coverage tool for ruby out there already? (i couldn't find it!)

My CSV module on RAA contains a similar coverage tool.
It's a topy and proof of concept thing but it might help you.
See
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/34968
for example.

Link to coverage.rb is at the bottom of
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/35186

Regards,
// NaHi