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.
  • Surely whatever about the future ExtUtils::MakeMaker is the standard now.

    Why is handling testing dependencies best done in the Makefile.PL/Build.PL? What are the advantages over skipping tests?
    • > Why is handling testing dependencies best done in the Makefile.PL/Build.PL?

      It's not so much "testing" as "checking".

      In multi-platform source packages (like CPAN packages) the dependencies of a package require turing-completeness to determine. That is, a dependency on your platform might be different to the dependencies on some other platform.

      Part of the job of the Configure phase (Makefile.PL and Build.PL) is to resolve the Complete Dependencies down to a set of Static Dependencies. That static list can then be picked up by the parent CPAN client and recursed to install the dependencies that the source package needs to be able to build on that platform.

      > What are the advantages over skipping tests?

      As we've gotten more and more into testing, we are realising that there are multiple classes of tests that we should be adding to modules.

      Most of these test basic functionality and so we need to execute them in all testing scenarios.

      But it's worthwhile adding other forms of testing to the modules. As chromatic points out, there are things like POD tests.

      Documentation quality tests make NO difference to the functionality of the module itself. When installing a module for production use, these tests are meaningless. To run them only creates more chances for unexpected false failures and increases the number of dependencies a module has. And dependency bloat is one of the great evils of CPAN-like systems, because it increases the complexity of the repository and means there's more chances for edge case errors to occur.

      The POD tests should, however, be run by the author on release (Release Tests) and should probably also be run on any automated mass-testing systems.

      Another class of tests are what you might call "unweildy tests". They allow for more-intensive testing, but they would place a heavy burdon on the user.

      For example, many database-related modules now include tests that only run on automated testing environments. These will add a dependency on DBD::SQLite, or other heavy modules, and do more thorough testing.

      But in the author's opinion, he has decided that a module which might be used only for MySQL shouldn't need to install SQLite JUST to do testing.

      A third class is optional features. Some modules will interact with CPAN modules IF they are installed, but don't need those modules to work normally.

      Adding a dependency makes no sense here, so the tests ONLY run if the optional module is available.