FAQ

Re: Tests failing when core extensions not built

Ed Allen Smith
Nov 1, 2004 at 1:35 am
In message (on 31 October 2004
20:13:43 -0500), schwern@pobox.com (Michael G Schwern) wrote:
On Sun, Oct 31, 2004 at 02:18:23PM -0500, Ed Allen Smith wrote:
I note that some lib tests appear to require various extensions; for
instance, Unicode/Normalize is required for Unicode/Collate to pass its
tests (see http://www.nntp.perl.org/group/perl.daily-build.reports/22308,
for instance). Scanning modules for use/require and building a data file
(e.g., via Test::Prereq) for such prerequisites may be in order (if no data
file, assume no such prerequisites are present, and optionally rebuild it
later?).
That would be centralizing internal details about individual modules, things
that can change with every new version.
I had in mind centralizing it, as such, only in a way that could be
automatically constructed, if at all possible.
The checks for unbuilt core modules are a special case that CPAN modules
and authors don't normally have to do.
True. Perhaps something like the above should instead be part of
Test::Smoke, and the build process should simply have an option of "read
this file for tests to skip", which could have uses in other circumstances?

-Allen

--
Allen Smith http://cesario.rutgers.edu/easmith/
September 11, 2001 A Day That Shall Live In Infamy II
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin
reply

Search Discussions

3 responses

  • Michael G Schwern at Nov 1, 2004 at 1:55 am ⇧

    On Sun, Oct 31, 2004 at 08:26:54PM -0500, Ed Allen Smith wrote:
    That would be centralizing internal details about individual modules, things
    that can change with every new version.
    I had in mind centralizing it, as such, only in a way that could be
    automatically constructed, if at all possible.
    I don't think it can be usefully automated.

    Consider this simple sort of problem.

    if( eval { require Some::Module } ) {
    * one version of the code *
    }
    else {
    * some other version *
    }

    The code still works fine even without the module in question being there.

    The checks for unbuilt core modules are a special case that CPAN modules
    and authors don't normally have to do.
    True. Perhaps something like the above should instead be part of
    Test::Smoke, and the build process should simply have an option of "read
    this file for tests to skip", which could have uses in other circumstances?
    No, you do not want Test::Smoke behaving differently from 'make test'.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    Hokey religions and taking a nap are no match for a knife in the head.
    -- Black Mage http://www.nuklearpower.com/daily.php?date=040513
  • Ed Allen Smith at Nov 1, 2004 at 2:13 am ⇧
    In message (on 31 October 2004
    20:55:47 -0500), schwern@pobox.com (Michael G Schwern) wrote:
    On Sun, Oct 31, 2004 at 08:26:54PM -0500, Ed Allen Smith wrote:
    That would be centralizing internal details about individual modules,
    things that can change with every new version.
    I had in mind centralizing it, as such, only in a way that could be
    automatically constructed, if at all possible.
    I don't think it can be usefully automated.

    Consider this simple sort of problem.

    if( eval { require Some::Module } ) {
    * one version of the code *
    }
    else {
    * some other version *
    }

    The code still works fine even without the module in question being there.
    Umm... is this likely to be tested for with a core module? And if
    testing for a core module is present, then the library module doing so would
    appear to be prepared for said core module not being present. That
    admittedly mainly says "default to assuming not required if uncertain".
    The checks for unbuilt core modules are a special case that CPAN modules
    and authors don't normally have to do.
    True. Perhaps something like the above should instead be part of
    Test::Smoke, and the build process should simply have an option of "read
    this file for tests to skip", which could have uses in other circumstances?
    No, you do not want Test::Smoke behaving differently from 'make test'.
    Urr... yes, wasn't thinking, sorry. It should be Test::Smoke using such a
    file, or internal data, to know what test failures to not automatically
    report as problematic, just as it now doesn't treat tests not confirmed by a
    harnessed failure as being cause to send to P5P (if so configured).

    -Allen

    --
    Allen Smith http://cesario.rutgers.edu/easmith/
    February 1, 2003 Space Shuttle Columbia
    Ad Astra Per Aspera To The Stars Through Asperity
  • Michael G Schwern at Nov 1, 2004 at 3:37 am ⇧

    On Sun, Oct 31, 2004 at 09:12:49PM -0500, Ed Allen Smith wrote:
    I don't think it can be usefully automated.

    Consider this simple sort of problem.

    if( eval { require Some::Module } ) {
    * one version of the code *
    }
    else {
    * some other version *
    }

    The code still works fine even without the module in question being there.
    Umm... is this likely to be tested for with a core module? And if
    testing for a core module is present, then the library module doing so would
    appear to be prepared for said core module not being present. That
    admittedly mainly says "default to assuming not required if uncertain".
    Who knows? You can't tell without a human examining the code.

    Urr... yes, wasn't thinking, sorry. It should be Test::Smoke using such a
    file, or internal data, to know what test failures to not automatically
    report as problematic, just as it now doesn't treat tests not confirmed by a
    harnessed failure as being cause to send to P5P (if so configured).
    All test failures are problematic. Do not start ignoring failures. That
    way madness lies.

    Its better in the long run to encode the proper skips and todos.


    --
    Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
    If I got anything to say, I'll say it with lead.
    -- Jon Wayne

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdaily-build @
Notice: Undefined variable: pl_domain_short in /home/whirl/sites/grokbase/root/www/public_html__www/cc/flow/tpc.php on line 1543
categoriesperl
postedNov 1, '04 at 1:35a
activeNov 1, '04 at 3:37a
posts4
users2
websiteperl.org

2 users in discussion

Ed Allen Smith: 2 posts Michael G Schwern: 2 posts