On Tue, May 30, 2006 at 11:27:51PM +0900, Victor Shepelev wrote:
> From: Suraj N. Kurapati [mailto:skurapat / ucsc.edu]
> Sent: Tuesday, May 30, 2006 5:22 PM
> > Victor Shepelev wrote:
> > > 4. optional code speed analysis (like benchmarking "how long it rans",
> > > profiling "what rans so long") after each test
> > 
> > See the 'profile' library provided in Ruby core.
> > 
> > ruby -r profile
> 
> No-no :)
> I know, how to do it _technically_.
> What I what to know is how to _organize_ all the task.
> Just for now I do only unit-tests, but _when_ to run benchmarking /
> profiling / coverage analysis / dependency analysis and so on? Must those
> tasks be ran automataically? When (after any code change, like unit tests?)
> This is a question.

As for coverage analysis: I run rcov before committing to make sure I'm not
checking in (lots of) untested code. This is how the task can be defined in
Rake:

require 'rcov/rcovtask'
desc "Create a cross-referenced code coverage report."
Rcov::RcovTask.new do |t|
  t.libs << "ext/rcovrt"
  t.test_files = FileList['test/test*.rb']
  t.rcov_opts << "--callsites"  # comment to disable cross-references
  t.verbose = true
end

and in Rant it'd be:

require 'rcov/rant'
desc "Create a cross-referenced code coverage report."
gen Rcov do |g|
  g.libs << "ext/rcovrt"
  g.test_files = sys['test/test*.rb']
  g.rcov_opts << "--callsites"  # comment to disable cross-references
end

This way  {rake,rant} rcov  will generate a XHTML report and show another
on stdout.

If your commits are small enough (or should I say "atomic"?), running the
tests just before committing (say with the pre-commit hook of your VCS) might
suffice. Otherwise (larger commits, or tests that don't want to pass) autotest
would be the way to go, I guess.


Regarding profiling, I don't think it makes any sense to run that
automatically in general.

-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby