Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Surely you want it in the CPAN Testers tests?

    AUTOMATED_TESTING instead?
    • That's very much a mixed bag. On one hand, yes, you clearly would want it in those tests. On the other, it's not confidence inspiring to see a lot of test failures when you're evaluating a module. Of course, people say "yes, but you should check to see what causes those failures", but this is problematic. Many, many times I've received a failure report with absolutely no information about why something has failed. Or I get a failure report with spurious information, which is just as annoying.

      If Schwern allows automated testing, not only does he have a good chance of getting bogus failure reports, he might find himself in the annoying position of getting into wasteful dialogues with some testers who aren't familiar with this issue and really, why should they be?

      OK, that was all just spewing as I sorted out my thoughts. I guess what would be good is to have a special type of "no report" test. In other words, a test which can fail, sort of like a TODO, but which automated tests shouldn't report. I'm unsure of the mechanism here. Didn't someone on Perl QA mention something like this, or am I smoking crack?