Grokbase Groups Perl qa January 2014
FAQ
It seems t/lib is a common place to put modules used to support testing,
how about having Test::More push that path to @INC if -d 't/lib' ? It would
save me one , possibly two annoying lines of code in every .t file I write.
With an import tag, ':automiport' or something, it could perhaps require
all .pm files in that dir too/instead?

personally I end up with use lib 't/lib' in 9 of 10 projects.

--
mvh
Torbjørn Lindahl

Search Discussions

  • D Perrett at Jan 31, 2014 at 3:12 am
    http://grep.cpan.me/?q=use+lib+%28%27|%22|q.%2B%3F%29t%2Flib - use lib
    ('|"|q.+?)t/lib - 948 distributions. Not all use Test::More, but
    probably most.

    But I would still expect a tag for pushing 't/lib' to @INC, not for
    Test::More to push to @INC silently, on the grounds that it's easier
    to add to @INC than remove from it if it turns out it's undesirable.

    For use within distribution tests, I can think of contrived examples
    where it would be cause failure or worse (e.g. t/lib/Data/Dumper.pm
    contains malicious code). Or perhaps:

         use Test::More;
         Check if some utility module can be loaded; if so, run test
    properly, using the full capacity of the module.
         Otherwise, use a module with same name, but less functionality in
    t/lib, and perform test minus the good bits.

    But I don't know of any actual, real-life examples. I can't see any
    way of answering this without smoke testing.

    Personally, I also use Test::More in circumstances other than testing
    a perl distribution. I don't know how widespread that is - those
    things are not going to appear on CPAN. For those things, adding t/lib
    could cause directories to appear in @INC surprisingly (albeit very
    rarely) and I think for such a core module, surprising things should
    not happen.

    Daniel
    On 30 January 2014 19:59, Torbjørn Lindahl wrote:
    It seems t/lib is a common place to put modules used to support testing, how
    about having Test::More push that path to @INC if -d 't/lib' ? It would save
    me one , possibly two annoying lines of code in every .t file I write. With
    an import tag, ':automiport' or something, it could perhaps require all .pm
    files in that dir too/instead?

    personally I end up with use lib 't/lib' in 9 of 10 projects.

    --
    mvh
    Torbjørn Lindahl
  • Ricardo Signes at Jan 31, 2014 at 3:20 am
    * Torbjørn Lindahl [2014-01-30T19:59:04]
    It seems t/lib is a common place to put modules used to support testing,
    how about having Test::More push that path to @INC if -d 't/lib' ? It would
    I suggest this alternative:

       use t::lib::MyPackage;

    ;)

    --
    rjbs
  • Leon Timmermans at Jan 31, 2014 at 3:25 am

    On Fri, Jan 31, 2014 at 1:59 AM, Torbjørn Lindahl wrote:
    It seems t/lib is a common place to put modules used to support testing,
    how about having Test::More push that path to @INC if -d 't/lib' ? It would
    save me one , possibly two annoying lines of code in every .t file I write.
    With an import tag, ':automiport' or something, it could perhaps require
    all .pm files in that dir too/instead?
    I don't like magical behavior. «use lib 't/lib';» is far more
    self-documenting, and automatically requiring all .pm files is plain evil.

    personally I end up with use lib 't/lib' in 9 of 10 projects.
    For me it's less than 1 in 10. I wouldn't be surprised if I'm closer to the
    average than you TBH, YMMV.

    Leon
  • D Perrett at Jan 31, 2014 at 3:36 am
    use t::lib::MyPackage;
    Nice tip!

    Searching on "use t::lib" led me to PPI which has both lib/PPI.pm and
    t/lib/PPI.pm - I suspect that they're not interchangeable and that
    trying to add t/lib to @INC would break its tests.

    Daniel
    On 30 January 2014 22:25, Leon Timmermans wrote:
    On Fri, Jan 31, 2014 at 1:59 AM, Torbjørn Lindahl
    wrote:

    It seems t/lib is a common place to put modules used to support testing,
    how about having Test::More push that path to @INC if -d 't/lib' ? It would
    save me one , possibly two annoying lines of code in every .t file I write.
    With an import tag, ':automiport' or something, it could perhaps require all
    .pm files in that dir too/instead?

    I don't like magical behavior. «use lib 't/lib';» is far more
    self-documenting, and automatically requiring all .pm files is plain evil.
    personally I end up with use lib 't/lib' in 9 of 10 projects.

    For me it's less than 1 in 10. I wouldn't be surprised if I'm closer to the
    average than you TBH, YMMV.

    Leon
  • Torbjørn Lindahl at Jan 31, 2014 at 11:34 am
    I agree, t::lib::Foo is really the obious solution to my first question.

    For the other part, I like that evil magic thing, I'll probably publish a
    separate module that requires and imports all pm files it finds under t/lib
    or someother assigned dir. It'll still be only one code line in my .t ,
    only should I put more pm files there it will do them all.

    Thanks.

    T.


    On Fri, Jan 31, 2014 at 4:36 AM, D Perrett wrote:

    use t::lib::MyPackage;
    Nice tip!

    Searching on "use t::lib" led me to PPI which has both lib/PPI.pm and
    t/lib/PPI.pm - I suspect that they're not interchangeable and that
    trying to add t/lib to @INC would break its tests.

    Daniel
    On 30 January 2014 22:25, Leon Timmermans wrote:
    On Fri, Jan 31, 2014 at 1:59 AM, Torbjørn Lindahl
    wrote:

    It seems t/lib is a common place to put modules used to support testing,
    how about having Test::More push that path to @INC if -d 't/lib' ? It
    would
    save me one , possibly two annoying lines of code in every .t file I
    write.
    With an import tag, ':automiport' or something, it could perhaps
    require all
    .pm files in that dir too/instead?

    I don't like magical behavior. «use lib 't/lib';» is far more
    self-documenting, and automatically requiring all .pm files is plain
    evil.
    personally I end up with use lib 't/lib' in 9 of 10 projects.

    For me it's less than 1 in 10. I wouldn't be surprised if I'm closer to the
    average than you TBH, YMMV.

    Leon


    --
    mvh
    Torbjørn Lindahl
  • David Cantrell at Jan 31, 2014 at 1:50 pm

    On Thu, Jan 30, 2014 at 10:36:19PM -0500, D Perrett wrote:
    use t::lib::MyPackage;
    Nice tip!
    That has a few caveats though.

    Your %INC will be a bit screwy, which may matter to some code. And it
    will fail to run MyPackage->import(), because t::lib::MyPackage::import
    doesn't exist.

       $ cat t/lib/MyPackage.pm
       package MyPackage;
       sub import { print "import() was called\n" }
       1;

       $ perl -e 'use t::lib::MyPackage;'

       $ perl -e 'use lib "t/lib";use MyPackage;'
       import() was called

    There may be other hidden weirdness that I've forgotten about.

    --
    David Cantrell | Godless Liberal Elitist

         Seven o'clock in the morning is something that
         happens to those less fortunate than me
  • Eirik Berg Hanssen at Jan 31, 2014 at 3:18 pm

    On Fri, Jan 31, 2014 at 2:50 PM, David Cantrell wrote:

    That has a few caveats though.

    Your %INC will be a bit screwy, which may matter to some code. And it
    will fail to run MyPackage->import(), because t::lib::MyPackage::import
    doesn't exist.

    $ cat t/lib/MyPackage.pm
    package MyPackage;
    sub import { print "import() was called\n" }
    1;

    $ perl -e 'use t::lib::MyPackage;'

    $ perl -e 'use lib "t/lib";use MyPackage;'
    import() was called

    There may be other hidden weirdness that I've forgotten about.

       Yeah; just name the package accordingly, and, screwy or not, it'll still
    work:

    package t::lib::MyPackage;
    sub import { print "import() was called\n" }
    1;

       :)


    Eirik
  • Ricardo Signes at Feb 1, 2014 at 12:24 am
    * Eirik Berg Hanssen [2014-01-31T10:17:53]
    Yeah; just name the package accordingly, and, screwy or not, it'll still
    work:

    package t::lib::MyPackage;
    sub import { print "import() was called\n" }
    This is my advice as well as my custom.


    --
    rjbs
  • James E Keenan at Feb 1, 2014 at 12:19 am

    On 1/30/14 10:25 PM, Leon Timmermans wrote:
    On Fri, Jan 31, 2014 at 1:59 AM, Torbjørn Lindahl<
    torbjorn.lindahl@gmail.com> wrote:
    It seems t/lib is a common place to put modules used to support testing,
    how about having Test::More push that path to @INC if -d 't/lib' ? It would
    save me one , possibly two annoying lines of code in every .t file I write.
    With an import tag, ':automiport' or something, it could perhaps require
    all .pm files in that dir too/instead?
    I don't like magical behavior. «use lib 't/lib';» is far more
    self-documenting, and automatically requiring all .pm files is plain evil.
    +1

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupqa @
categoriesperl
postedJan 31, '14 at 12:59a
activeFeb 1, '14 at 12:24a
posts10
users7
websiteqa.perl.org

People

Translate

site design / logo © 2019 Grokbase