From: Mauricio Fernandez <mfp@...>
Date: 2006-08-07T20:40:45+09:00
Subject: Re: [ANN] rcov 0.7.0 (code coverage for Ruby)

On Mon, Aug 07, 2006 at 12:15:30PM +0900, Robert MannI wrote:
> I am wondering, for a rails project, would this be the correct way to use
> this?
> 
> rcov -Ilib test/**/*.rb
> 
> That works for me, albeit about 30% of my tests fail then, while when I run
> them using the rake task ("rake"), they all pass. So I suppose I must be
> doing something wrong.

As Assaph said, this can fail in some circumstances, the reason being that
unit, functional and integration tests cannot always be run in the same
process safely; this is why the test task in Rails apps executes them
separately.

So, if you are lucky and there are no clashes, just

  rcov --rails -Ilib test/**/*_test.rb

would do. --rails tells rcov to ignore config/, environment/ and vendor/ in
the statistics.

Now, if you see that the outcome of the tests when run as shown above differs
from the results given by  rake test (as happened to you), you have to execute
unit, functional and integration tests in three different processes.
You can do it manually as follows:

  rm -f coverage.data
  rcov --no-html  --rails --aggregate coverage.data -Ilib test/unit/*_test.rb
  rcov --no-html --rails --aggregate coverage.data -Ilib test/functional/*_test.rb
  rcov --rails --aggregate coverage.data -Ilib test/integration/*_test.rb

--aggregate is used to merge the coverage data from the three runs in a
single report; --no-html is used in the first two runs because anyway the
last execution will create the report with all the information.

If you want a recipe to automate that, have a look at 
 http://eigenclass.org/hiki.rb?rcov+0.7.0
where I show a small snippet you can dump into e.g. lib/tasks/rcov.rake.
It will generate a number of tasks in the test:coverage namespace, as well as
a test:coverage task that runs all the tests under rcov.

Unfortunately, --aggregate is relatively slow because it has to save quite a
lot of information across runs: all the Ruby code that was parsed, the
coverage data, etc. There's no way around that though. Of course, you can also
create separate reports for unit, functional and integration tests (using -o
to choose the destination dirs for the reports, and omitting --aggregate),
but you won't be able to obtain a single unified coverage rate that way.

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