Devel::Cover recommendations... or maybe not?

   Dear bonders, I need to recommend some tools for QA at
$company.

   Maybe some of you can tell me good (or bad) impressions
about  
Devel::Cover.

   The POD scares everybody, stating clearly "this is
alfa code".  
It's almost like saying "go away" what is pretty
strange for an open- 
source module...

   Comments, anybody?
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software
engineer,
Perl fanatic evangelist, and amateur {cook, photographer}

On 14 Mar 2007, at 16:18, Luis Motta Campos wrote:

>   Dear bonders, I need to recommend some tools for QA
at $company.
>
>   Maybe some of you can tell me good (or bad)
impressions about  
> Devel::Cover.
>
>   The POD scares everybody, stating clearly "this
is alfa code".  
> It's almost like saying "go away" what is
pretty strange for an  
> open-source module...
>
>   Comments, anybody?

Used heavily at $company-1 to generate pretty tables of
coverage.

What you *do* with the info is another story...
-- 
Dave Hodgkinson - Music photography
http://www.davehodgkin
son.com/

--- Luis Motta Campos <luismottacamposyahoo.co.uk> wrote:

>    Dear bonders, I need to recommend some tools for QA
at $company.
> 
>    Maybe some of you can tell me good (or bad)
impressions about  
> Devel::Cover.
> 
>    The POD scares everybody, stating clearly "this
is alfa code".  
> It's almost like saying "go away" what is
pretty strange for an open-
> 
> source module...
> 
>    Comments, anybody?

Ignore that comment.  I have a cronjob which rebuilds my
coverage
reports nightly and all of my colleagues can simply check
the coverage
Web site I have set up (I'm reasonably sure that none of
them have,
however).

It's a fantastic fantastic tool.  There are more features I
want with
it, but the features I want are simple enough that I should
get off my
duff and supply a patch.

Cheers,
Ovid

--

Buy the book -- http://www.or
eilly.com/catalog/perlhks/
Perl and CGI -- http://u
sers.easystreet.com/ovid/cgi_course/

On 14 Mar 2007, at 15:18, Luis Motta Campos wrote:

>   Dear bonders, I need to recommend some tools for QA
at $company.
>
>   Maybe some of you can tell me good (or bad)
impressions about  
> Devel::Cover.
>
>   The POD scares everybody, stating clearly "this
is alfa code".  
> It's almost like saying "go away" what is
pretty strange for an  
> open-source module...
>
>   Comments, anybody?

I've had no problems with it. It's great as long as you
remember the  
limitations of coverage testing - i.e. just because it's
been  
executed doesn't mean it's correct.

-- 
Andy Armstrong, hexten.net

On 14 Mar 2007, at 15:18, Luis Motta Campos wrote:

>   Dear bonders, I need to recommend some tools for QA
at $company.
>
>   Maybe some of you can tell me good (or bad)
impressions about  
> Devel::Cover.
[snip]

Great tool. Love it to death... just don't misuse coverage
reports to  
do silly things, so make sure folk read docs like the
classic "How to  
misuse code coverage" 

	<http
://www.testing.com/writings/coverage.pdf>

Adrian

On Mar 14, 2007, at 4:39 PM, Dave Hodgkinson wrote:
> On 14 Mar 2007, at 16:18, Luis Motta Campos wrote:
>>  Dear bonders, I need to recommend some tools for
QA at $company.
>>
>>   Maybe some of you can tell me good (or bad)
impressions about  
>> Devel::Cover.
>>
>>   The POD scares everybody, stating clearly
"this is alfa code".  
>> It's almost like saying "go away" what is
pretty strange for an  
>> open-source module...
>>
>>   Comments, anybody?
>
> Used heavily at $company-1 to generate pretty tables of
coverage.
>
> What you *do* with the info is another story...

   What is adviseable to *do* with this info?
   Is there any problem in using this info as a guideline
for  
programmer time investment on testing improvements?

   Thanks for the answers, btw.
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software
engineer,
Perl fanatic evangelist, and amateur {cook, photographer}

On Mar 14, 2007, at 5:00 PM, jesse wrote:
>> Ignore that comment.  I have a cronjob which
rebuilds my coverage
>> reports nightly and all of my colleagues can simply
check the  
>> coverage
>> Web site I have set up (I'm reasonably sure that
none of them have,
>> however).
>
> You should post your cronjob ;) It'd be useful to
folks. Even if  
> it's a
> two line shell script.

   Yeah, I agree.
   That will save me two lines coding something that is
already coded  
somewhere on the universe. And will guarantee Ovid yet
another beer  
against me on his beer-chart 

--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software
engineer,
Perl fanatic evangelist, and amateur {cook, photographer}

On Mar 14, 2007, at 8:18 AM, Luis Motta Campos wrote:

> The POD scares everybody, stating clearly "this is
alfa code". It's  
> almost like saying "go away" what is pretty
strange for an open- 
> source module...

:(

It's very frustrating to read that.

Perl provides no sensible mechanism for deprecation or major
version  
incrementing, and because compile-time and run-time are not 

separated, compile-time errors cause immediate run-time
errors.   
Faced with that situation, if you are the author of a CPAN
library  
that may break backwards compatibility at any time in the
future, the  
most responsible thing to do is declare your code
perpetually  
"alpha", regardless of stability.

I've had such a warning on KinoSearch since it was first
released.   
It does not translate to "go away".

Marvin Humphrey
Rectangular Research
http://www.rectangular.co
m/

On 2007/03/14, at 16:18, Luis Motta Campos wrote:

>   What is adviseable to *do* with this info?
>   Is there any problem in using this info as a
guideline for  
> programmer time investment on testing improvements?

Basically, Devel::Cover gives you a bunch of information of
what  
pieces of code your tests are not covering. So, the goal of
using it  
is using that information to improve tests. 

Good luck 

--
Igor Sutton
igor.suttongmail.com

On Wed, Mar 14, 2007 at 05:18:31PM +0100, Luis Motta Campos
wrote:
> On Mar 14, 2007, at 4:39 PM, Dave Hodgkinson wrote:
> >On 14 Mar 2007, at 16:18, Luis Motta Campos wrote:
> >>  Maybe some of you can tell me good (or bad)
impressions about  
> >>Devel::Cover.
> >Used heavily at $company-1 to generate pretty
tables of coverage.
> >What you *do* with the info is another story...
> 
>   What is adviseable to *do* with this info?
>   Is there any problem in using this info as a
guideline for  
> programmer time investment on testing improvements?

I think that's definitely one thing you can do with it. If
you need to
persuade your management that programmer time spent on
testing is a good
thing, you need metrics for quality. Devel::Cover can help
you to
measure your test coverage, and thus the areas where you
need to improve
or modify your testing.

Software engineering involves QA. Coverage analysis with a
pretty
clickable report like Devel::Cover can help you in several
ways:
	- ensure your tests cover your code
	- show you which methods/branches/conditionals are naked
	- show you which _other_ classes your tests reach into
The last one is a big win for me. Unit testing means testing
units of
code in isolation. If I'm testing my LinkFactory class, I
mock my
various Link objects, to ensure that my tests are against
the
LinkFactory only. By running the tests against a single
class at a time,
and generating a Devel::Cover report, I can see which other
classes are
being analysed for coverage and mock those - essentially
D::C is telling
me "these are the methods/conditionals/... you need to
test, and these
are the classes you need to mock if you want your tests to
be granular".

In general, though, increasing coverage across an
application is a 
great game for a dev team to play. Build a
continuous-integration test
server which runs your test suite under Devel::Cover every
time a commit
hits your source control repository. Obviously, this gives
you an
automatic notification when your source tree is broken, but
you can use
the coverage numbers to flag commits which lower, rather
than raise,
coverage. You can run reporting to see which developers in a
team are
responsible for improving/lowering coverage. I think that is
exactly the
kind of quality metric of which management would approve.
And the
general optimisation of team duties is much easier when the
managers are
aware of the relative strengths of each team member. It also
helps with
appraising programmers in performance reviews to have a
metric for their
performance as part of the team, as an engineer.

/joel