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

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.
  • Is that a common problem, installation failures? Instead of installing the tests somewhere can't it just do some kind of -I to get @INC set?

    I don't know of any traditional location for tests in production and I'd rather there not be a pile of clutter under my @INC directories while a dozen different people all decide to use some different scheme for storing their tests somewhere.
    • I want you to install your (Test::Class-based) tests as normal modules so I can reuse it when I reuse your modules.

      • That is just the mental shove I needed to see why I'd possibly ever care about Test::Class. Thanks!
        • There are plenty of other reasons to use Test::Class. Do you have thirty t/*.t programs? You've just loaded the perl runtime at least 30 times (probably more). You've also probably reloaded the tested modules many times and possibly duplicated a lot of test code. With Test::Class, you only load the Perl interpreter once and the associated modules once. Large test suites can run much faster and are easier to refactor.

          And inheriting tests to ensure that derived classes don't break their parents makes m

  • I should note that I blogged about it here [], with some more information.

  • Even if a distribution lacks a ./t directory, it may have a script. Hence, you may want to adjust your criteria for discarding untestable distributions.
    • I had considered that, but a number of modules don't output TAP (largely because they're older code). As a result, my parser can't reliably parse their output. My goal here, in reality, is not to test all of the CPAN, but to have a massive stress test of TAPx::Parser []. I still have several thousand test suites left which I can use and I've found a few bugs I need to address.

      That being said, I doubt all tests in t/*.t are based on Perl's regular testing tools, but I have to start somewhere.

      • Yes, I had considered that you had considered that.

        In which case, it would be handy to know what scripts aren't TAP-compliant. I know early versions of Compress::Bzip2 (before it was taken over by the current maintainer) featured a test script that produced nothing useful.

        It would be nice to have an exhaustive list. Then we could go about fixing them, if the distributions in question are useful enough to be worth the attention.