All the Perl that's Practical to Extract and Report
use Perl Log In
barbie (2653)
reversethis-{ku. ... m} {ta} {eibrab}
http://barbie.missbarbell.co.uk/
Leader of Birmingham.pm [pm.org] and a CPAN author [cpan.org]. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [yapc-surveys.org] and the QA Hackathon [qa-hackathon.org] websites. Also the current caretaker for the CPAN Testers websites and data stores.
If you really want to find out more, buy me a Guinness
Links:
Memoirs of a Roadie [missbarbell.co.uk]
[pm.org]
CPAN Testers Reports [cpantesters.org]
YAPC Conference Surveys [yapc-surveys.org]
QA Hackathon [qa-hackathon.org]
CPAN POD testing
I currently use Test::Pod and Test::Pod::Coverage in all my distributions by default. I also plan to use Test::Distribution once I get the time to slot it in. However, not everyone does. As a consequence some trivial mistakes can slip through, which although not essential to the coding, are obviously worth noting for future releases. The thought I had was, along side the CPAN testing, to run a set of simple test scripts which run the three above mentioned modules against a named distribution.
Back when I did my CPAN Testing talk earlier in the year, this was something that crossed my mind, but as I was too busy doing other things, didn't really formulate how to do it. I have pondered about it off and on for a few months, and since the post mentioned today, the thought has popped up again. At some point I'd like to do this, but wonder how people would receive it. Note that any mails would only be sent to the author, and not to the cpan-testers list, as it's more a request for enhancement. Would an RT entry be prefered, sending to the CPANID, another method or just a really bad idea? Picking and choosing would not be possible, and personally would prefer the CPANID mailing that currently happens for CPAN testings, as it's the easiest to do.
Thoughts?
I wonder whether this might be a lightning talk?
--Larry Wall in stab.c from the perl source code
CPAN Testing (Score:1)
I'll do a talk on it at YAPC::Europe in Belfast, and if you (and others) are interested, we could do a BOF.
For a short preview, CPANTS currently creates YAML-files for each dist containing various information. Additionally, it creates a SQLite DB for easy querying of stuff.
Here's the yaml-file for Acme::Bleach (which contains 3 pod errors):
--- #YAML:1.0
dist: Acme-Bleach-1.12
distribution:
Re:CPAN Testing (Score:2)
However, are you also a producing a report of the errors you've found. In some cases rerunning the tests on a.n.other box may not spot the problems, so it's handy to have a detailed list of what you tested with (Test:: module versions too) as well as the errors.
Re:CPAN Testing (Score:1)
But including versions of important modules used (and perl version, BTW) is a good idea. Thanks!
BTW. I ran CPANTS today, you can view the results here (this is a very temporary URI..):
http://test1.dev.zsi.at/ [dev.zsi.at]
(very raw results, that is: yaml-files in directory metrics, and a sqlite DB. no docs currently, sorry)
Re:CPAN Testing (Score:2)
What's ninja (in files)?
Re:CPAN Testing (Score:1)
"Ninja" was a topic at the CPLAN meeting, but not discussed (I think).
So I got interested and did some research (using CPANTS). All people using it are employed by Fotango. It containts what looks like roleplaying stats (Strenght, Dexterity, etc). But I don't know what it's for...
eg: http://search.cpan.org/src/LBROCARD/Data-Page-1.03/NINJA [cpan.org]
CPANTS YAML output (Score:1)
Re:CPANTS YAML output (Score:1)
And because the YAML gets dumped into a text field in a database, anyway.
Hmm..., when I think about it, I could dump the YAML array into the textfield.
Thanks for the suggestion..