in reply to Re^2: How to specify tests dependencies with Makefile.PL?
in thread How to specify tests dependencies with Makefile.PL?

It certainly should. As I mentioned in my post above, BUILD_REQUIRES isn't specifically for the testing phase. It's for the build phase, which is actually earlier than the test phase. It's the place to list build dependencies, but happens to also be a good place for listing test dependencies. The reason I say it's a good place is this: It's my opinion (and only my opinion) that PREREQ_PM should be reserved for your module's actual dependencies. CONFIGURE_REQUIRES should be reserved for Makefile.PL's dependencies. BUILD_REQUIRES should be used for anything that is essential to the 'make' process or the make test process, but that is not essential for the target module itself once it's installed.

These aren't the only hooks either. There are additional hooks for installing executables, and other paraphernalia. But when it comes to dependencies that are themselves actually modules, these are the three points of interest.


Dave

Replies are listed 'Best First'.
Re^4: How to specify tests dependencies with Makefile.PL?
by OlegG (Monk) on Jan 03, 2012 at 14:45 UTC
    Hmm, in this case test dependencies becomes hard dependencies for end user. So, for this user there is no difference between PREREQ_PM and BUILD_REQUIRES, he should install both (if he used cpan shell).
    It seems all that I can is to ask user:
    ExtUtils::MakeMaker::prompt("Do you want testing support for this module?\nThis requires additional modules to be installed: XX::YY, YY::ZZ", "yes");
    However it will be strange question when notest pragma specified in the cpan shell. But it seems I can't determine from Makefile.PL is it specified, I didn't found how.
[reply]
[d/l]

      There's probably a better approach. When's the last time you were prompted as to whether or not you want to test the module you're about to install? Perhaps not unheard of, but certainly rare. While test dependencies are not rare.

      There are other ways to handle it. One solution could be to compose as many tests as practical that don't require this dependency. Then create another group of tests that do require this dependency. Wrap these tests in a SKIP:{...} block, as described in Test::More - Conditional tests.

      That way, if the dependency exists, the test will run. If not, you can supply a message about why certain tests are being skipped, and move on.

      Of course you do have to decide how important it is for those tests to run. On some of the modules I've been working on recently (Inline related stuff) the tests are critical to assuring that the user will actually be able to use the module. And it's entirely possible for some of my tests to fail on certain systems. You may be in such a situation, or you may be in a situation where the code being tested is pretty reliable and portable -- where a pass on one system is almost certain to equate to a pass on all systems that meet minimum version requirements.

      If you're closer to my situation where from one system to the next tests can perform differently, you wouldn't want to skip a critical test. If your module is built on more stable ground, or if the components tested by the dependency are pretty stable, you may be Ok with skipping them.

      If you do feel it's important to run the tests on all systems, don't be afraid to pull down a test dependency. It's pretty common to do so.


      Dave

[reply]
[d/l]
        Ok, thanks. I will choose the most appropriate variant for me.
[reply]

In Section Seekers of Perl Wisdom