Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

barbie (2653)

  reversethis-{ku. ... m} {ta} {eibrab}

Leader of [] and a CPAN author []. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [] and the QA Hackathon [] 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 ;)

Memoirs of a Roadie []
CPAN Testers Reports []
YAPC Conference Surveys []
QA Hackathon []

Journal of barbie (2653)

Wednesday July 21, 2004
01:13 PM

CPAN POD testing

[ #19978 ]
A post was made on the list today, regarding some POD errors in a recent distribution, and reawoke a thought I had sometime ago, but one I haven't gotten around to implementing.

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.


I wonder whether this might be a lightning talk?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I'm currently working on CPANTS (finally found/took some time..). CPANTS does pod testing. And a lot of other things.

    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
    • Looks like you gone a lot further than I was thinking, great stuff. I will be very interested to hear your talk, assuming I'm not schedule to talk at the same time, so will be along if I can.

      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.

      • I'm planning to include various pieces of metadata in the results like the version of CPANTS used to generate data.

        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..): []
        (very raw results, that is: yaml-files in directory metrics, and a sqlite DB. no docs currently, sorry)
  • Why not use normal YAML arrays, like this?
    bad_permissions: []
        - demo
        - lib
        - lib/Acme
        - t
        - Changes
        - MANIFEST
        - ...
    symlinks: []
    • Because I'm lazy :-)

      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..