Hi everyone, I was reading through the Rails book again, and I came across a mention of Ruby Coverage: ----- Ruby Coverageis a free coverage tool (not yet included with Ruby or Rails) that outputs an HTML report including the percentage of coverage, with the lines of code not covered by tests highlighted for your viewing pleasure. To generate a report, add the -rcoverage option to the ruby command when running tests. depot> ruby -rcoverage test/functional/store_controller_test.rb ----- I installed it, but it''s not working correctly: ----- $ ruby -rcoverage test/functional/personnel_controller_test.rb ruby: No such file to load -- coverage (LoadError) ----- The developer seems to not have touched it in a while, and I can''t find any good documentation for it. Instead of wrestling with this, I thought I''d ask if there are any good more recently updated alternatives to this tool. Thanks! Sean
I failed to use it too, and I have previously posted it to the list. Or nobody is taking care of the covergae of the Tests, or they are using other tool that I didn''t find. -- Aníbal Rojas anibalrojas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org On 10/24/05, Sean Hussey <seanhussey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi everyone, > > I was reading through the Rails book again, and I came across a > mention of Ruby Coverage: > > ----- > Ruby Coverageis a free coverage tool (not yet included with Ruby or Rails) > that outputs an HTML report including the percentage of coverage, with > the lines of code not covered by tests highlighted for your viewing pleasure. > To generate a report, add the -rcoverage option to the ruby command when > running tests. > > depot> ruby -rcoverage test/functional/store_controller_test.rb > ----- > > I installed it, but it''s not working correctly: > > ----- > $ ruby -rcoverage test/functional/personnel_controller_test.rb > ruby: No such file to load -- coverage (LoadError) > ----- > > The developer seems to not have touched it in a while, and I can''t > find any good documentation for it. Instead of wrestling with this, I > thought I''d ask if there are any good more recently updated > alternatives to this tool. > > Thanks! > > Sean > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Oct 24, 2005, at 11:35 AM, Aníbal Rojas wrote:> I failed to use it too, and I have previously posted it to the list. > Or nobody is taking care of the covergae of the Tests, or they are > using other tool that I didn''t find. > > -- > Aníbal Rojas > anibalrojas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.orgI will have something out this week for doing Rails coverage. It''s pretty fast, too. -- Scott Barron Lunchbox Software http://lunchboxsoftware.com http://lunchroom.lunchboxsoftware.com http://rubyi.st
I know this might be a little controversial, but I can''t say that I''m convinced by the idea of coverage tools - unless they do something deeper that I haven''t twigged yet. I can see how it''s good to know if code isn''t covered by *any* tests, but I can also see how one could be lulled into a false sense of security by 100% coverage, because (I presume) the coverage tools can''t tell you anything about the completeness of the tests themselves. For example, if you''re testing numericality of a method with a float result, the coverage tool will tell you if you''ve covered the method, but can''t know if (for example) NaN or Inf can ever come out, under what circumstances they should, and so on. I guess the point I''m trying to make is that I can''t see a coverage tool being a substitute for test-first development, where you *know* that all the production code is covered. Am I completely off base here? The one scenario I *can* see them being useful in is retrofitting test suites to legacy code. Is that the primary use case? I''m not trying to knock peoples'' hard work here, just trying to get my head around something I don''t really understand... -- Alex Scott Barron wrote:> > On Oct 24, 2005, at 11:35 AM, Aníbal Rojas wrote: > >> I failed to use it too, and I have previously posted it to the list. >> Or nobody is taking care of the covergae of the Tests, or they are >> using other tool that I didn''t find. >> >> -- >> Aníbal Rojas >> anibalrojas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > I will have something out this week for doing Rails coverage. It''s > pretty fast, too. >
Alex,> I know this might be a little controversial, but I can''t say > that I''m convinced by the idea of coverage tools - unless > they do something deeper that I haven''t twigged yet.This is a software developers list, everything is controversial ;-)> I can see how it''s good to know if code isn''t covered by > *any* tests, but I can also see how one could be lulled > into a false sense of security by 100% coverage, because > (I presume) the coverage tools can''t tell you anything about > the completeness of the tests themselves.You are right, but in a shared/OPen Source development environment is great to be able to quickly gather suchs kind of metrics.> For example, if you''re testing numericality of a method with > a float result, the coverage tool will tell you if you''ve covered > the method, but can''t know if (for example) NaN or Inf can > ever come out, under what > circumstances they should, and so on.I agree.> I guess the point I''m trying to make is that I can''t see > a coverage tool being a substitute for test-first development, > where you *know* that all the production code is covered. > Am I completely off base here?Again, I agree that such a simple metric wont replace such a work, but not everybody practices "test first".>The one scenario I *can* see them being useful in is >retrofitting test suites to legacy code. Is that the primary >use case? > > I''m not trying to knock peoples'' hard work here, just trying > to get my > head around something I don''t really understand... >Don''t do it, you''ll end full of bumps ;-) Regards -- Aníbal Rojas anibalrojas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> -- > Alex > > Scott Barron wrote: > > > > On Oct 24, 2005, at 11:35 AM, Aníbal Rojas wrote: > > > >> I failed to use it too, and I have previously posted it to the list. > >> Or nobody is taking care of the covergae of the Tests, or they are > >> using other tool that I didn''t find. > >> > >> -- > >> Aníbal Rojas > >> anibalrojas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > > > I will have something out this week for doing Rails coverage. It''s > > pretty fast, too. > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Oct 25, 2005, at 5:22 AM, Alex Young wrote:> I know this might be a little controversial, but I can''t say that I''m > convinced by the idea of coverage tools - unless they do something > deeper that I haven''t twigged yet. > > I can see how it''s good to know if code isn''t covered by *any* tests, > but I can also see how one could be lulled into a false sense of > security by 100% coverage, because (I presume) the coverage tools can''t > tell you anything about the completeness of the tests themselves. For > example, if you''re testing numericality of a method with a float > result, > the coverage tool will tell you if you''ve covered the method, but can''t > know if (for example) NaN or Inf can ever come out, under what > circumstances they should, and so on. > > I guess the point I''m trying to make is that I can''t see a coverage > tool > being a substitute for test-first development, where you *know* that > all > the production code is covered. Am I completely off base here? > > The one scenario I *can* see them being useful in is retrofitting test > suites to legacy code. Is that the primary use case? > > I''m not trying to knock peoples'' hard work here, just trying to get my > head around something I don''t really understand... > > -- > AlexNobody ever called coverage analysis of any kind a replacement for test driven development. Coverage analysis does not replace anything, it augments. I found this article [1] to be a particularly good explanation of the hows and whys of the different types of coverage analysis, and what benefits they serve. It also explains in detail why you should not rely on CA tools as your only indicator of "correctness". Writing tests first does not guarantee that your tests are covering every scenario your code anticipates. Tests are written by humans and, thus far, humans have not been infallible. Everyone makes mistakes, everyone misses something sometimes. CA tools won''t reduce the number of mistakes to 0, but when used smartly they can help in many situations. [1] http://www.bullseye.com/coverage.html -- Scott Barron Lunchbox Software http://lunchboxsoftware.com http://lunchroom.lunchboxsoftware.com http://rubyi.st