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.
  • I, too, am tired about false test failure reports. However, my reaction has been just to ignore them them most of the time.
    • That sounds nice, but false negatives are as bad as false positives. People either have to dig in and find out if it's really a failure or they learn to ignore failures, force the install and then complain when the module doesn't work. It's very important that this issue get resolved.

      Of course, there's yet another class of folks: those who won't install anything with test failures reported. If I have a choice amongst several modules, I don't want to dig through all of the test reports. As a result, I'

      • Do people really pay attention to those test reports? I seem to remember them always being pretty bogus, with lots of failure reports for popular modules that obviously work. In my opinion, there isn't enough agreement about the purpose and extent of unit tests on CPAN modules for the test reports to be meaningful when choosing a module.
        • So are you suggesting that having useful test reports is not a worthwhile goal? I don't think you are.

          • I'm suggesting that having useful test reports is not an achievable goal, given the current lack of rules for CPAN tests. If you ask ten different authors what the tests on CPAN modules are for, you'll get ten different answers. Many don't intend for end users to run them at all. And there isn't any accepted way to say "this forking module should not be auto-tested on Windows, since it isn't intended to work there." I think the automated testing of all CPAN modules was a neat idea, but ultimately yields