Re: Test module for tests in Perl module distro
On Tue, Jul 7, 2009 at 9:21 PM, Michael G Schwernschw...@pobox.com wrote: Mark Morgan wrote: [1] Test::Class is my preferred testing package for work; I don't use it for stuff destined for CPAN due to adding an extra dependancy. *sigh* Your CPAN modules already depend on things like Moose and Hook::LexWrap and XML::Parser. Leaving out Test::Class at that point is, at best, Pyhrric. Yeah, probably true anymore. I generally adopted this approach years back, when places that I worked at (at the time a number of ISPs) chances of installing any modules was inversely proportional to the number of dependancies it had... Mark.
Re: Test module for tests in Perl module distro
- Original Message From: Mark Morgan makk...@gmail.com [1] Test::Class is my preferred testing package for work; I don't use it for stuff destined for CPAN due to adding an extra dependancy. *sigh* Your CPAN modules already depend on things like Moose and Hook::LexWrap and XML::Parser. Leaving out Test::Class at that point is, at best, Pyhrric. Yeah, probably true anymore. I generally adopted this approach years back, when places that I worked at (at the time a number of ISPs) chances of installing any modules was inversely proportional to the number of dependancies it had... I would check to see the likelihood of failure to install a given module and if that's a low % chance relative to the benefits you gain, I'd include it. Regrettably, Test::Class has a relatively high failure rate and thus I'd be less inclined to include it :( That being said, I've been a rather naughty CPAN developer in that I've sometimes included modules in 'requires' which *I* think are really important or common, thus decreasing the chance that my module will be installed, but increasing the chance, if it's installed, that others who depend on it will install successfully. Hopefully that will also make programmers more likely to use it if it's already there. Yeah, I know. That's not really nice :) Cheers, Ovid-- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Test module for tests in Perl module distro
On Tue, Jul 7, 2009 at 3:15 AM, Michael G Schwernschw...@pobox.com wrote: use lib 't/lib'; chdir 't'; require Some::Module::In::t::lib; lib.pm does not make the directory absolute, so it leaves your program vulnerable to the above problem. Its rare you'd have to require instead of use, some load order issues make it necessary, but it sure it annoying when it happens. I'll generally go with the convention of having a 't/lib', and adding that via 'use lib qw( t/lib)'. Within there, all packages are prefixed with 't' also, so for testing Foo package, the relevant test libs will be located in 't/lib/t/Foo', and the package names being 't::Foo'. This was initially adopted because Test::Class [1] historically (maybe still) had problems with some package names conflicting with inner packages used by itself. It also has the benefit of being able to easily determine which are test packages and which are part of the application itself. Mark. [1] Test::Class is my preferred testing package for work; I don't use it for stuff destined for CPAN due to adding an extra dependancy. *sigh*
Re: Test module for tests in Perl module distro
Mark Morgan wrote: [1] Test::Class is my preferred testing package for work; I don't use it for stuff destined for CPAN due to adding an extra dependancy. *sigh* Your CPAN modules already depend on things like Moose and Hook::LexWrap and XML::Parser. Leaving out Test::Class at that point is, at best, Pyhrric. -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: Test module for tests in Perl module distro
David Golden wrote: On Sun, Jul 5, 2009 at 9:40 PM, Buddy Burdenbarefootco...@gmail.com wrote: Let's say I have some common functions that I want available to all my .t files. So I've created a module that all the .t files can include. But where do I put it? I don't want to put it in lib/ because I don't want it to get installed, right? But when I put it in t/, make test can't seem to find it. I tend to see three variations. They're all fine. Here's my opinions. (1) put it in t/lib/MyTest.pm and use lib 't/lib' at the start of your test files This is my preferred way of doing things. Using lib::abs avoids any problems if your test code has to chdir(). (2) put it in t/MyTest.pm and use lib 't' at the start of your test files I don't like this because it clutters up the test directory. We have subdirectories for a reason. (3) either of the above but use t::MyTest rather than changing @INC with use lib... Has all the problems of #2, plus it wields your testing module to the t/ directory. If you want to move it or package it into its own dist you have to change the package name. If its a class you're writing t::MyTest- If for some reason your code has to chdir() before loading the module there's no way to compensate for that. I don't think any one is much better than the others. I tend to like the t::MyTest approach from a readability standpoint because it's clear within the *.t file that this is a test library and it's clear where to locate it. -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email?
Re: Test module for tests in Perl module distro
Hi Michael, et al,
Personally, unless I have a very complicated (and therefore unusual)
test setup, simply putting .pm files directly in t/ works just fine.
Then a simple use lib './t' does the trick. `prove`, `make test` and
even Test::Harness::run_tests(glob 't/*.t') ignore anything but .t
files, and are basically always [TMK] executed from your package's
base directory. So, seeing files ending in .pm inside a t/ directory,
makes their purpose and contents completely unambiguous IMO.
I'm not sure I understand the concern about chdir(). Since use lib
is a compile time directive, then whether your code chdir()s at run
time or not seems to me to be a moot point. ??
Yet-Another [cross-platform-compatible] possibility, which [TMK] works
around your cited chdir() issue is to do the following.
code
BEGIN {
use Cwd 'abs_path';
use File::Spec;
my ($vol, $dir) = File::Spec-splitpath(abs_path($0)); # use
script name to find t/
push @INC, $vol.$dir;
}
/code
Cheers,
--
Shaun Fryer
http://sourcery.ca/
On Mon, Jul 6, 2009 at 4:59 PM, Michael G Schwernschw...@pobox.com wrote:
David Golden wrote:
On Sun, Jul 5, 2009 at 9:40 PM, Buddy Burdenbarefootco...@gmail.com wrote:
Let's say I have some common functions that I want available to all my
.t files. So I've created a module that all the .t files can include.
But where do I put it? I don't want to put it in lib/ because I
don't want it to get installed, right? But when I put it in t/, make
test can't seem to find it.
I tend to see three variations.
They're all fine. Here's my opinions.
(1) put it in t/lib/MyTest.pm and use lib 't/lib' at the start of
your test files
This is my preferred way of doing things. Using lib::abs avoids any problems
if your test code has to chdir().
(2) put it in t/MyTest.pm and use lib 't' at the start of your test files
I don't like this because it clutters up the test directory. We have
subdirectories for a reason.
(3) either of the above but use t::MyTest rather than changing @INC
with use lib...
Has all the problems of #2, plus it wields your testing module to the t/
directory. If you want to move it or package it into its own dist you have to
change the package name. If its a class you're writing t::MyTest-
If for some reason your code has to chdir() before loading the module there's
no way to compensate for that.
I don't think any one is much better than the others. I tend to like
the t::MyTest approach from a readability standpoint because it's
clear within the *.t file that this is a test library and it's clear
where to locate it.
--
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
Re: Test module for tests in Perl module distro
Shaun Fryer wrote:
Personally, unless I have a very complicated (and therefore unusual)
test setup, simply putting .pm files directly in t/ works just fine.
Then a simple use lib './t' does the trick. `prove`, `make test` and
even Test::Harness::run_tests(glob 't/*.t') ignore anything but .t
files, and are basically always [TMK] executed from your package's
base directory. So, seeing files ending in .pm inside a t/ directory,
makes their purpose and contents completely unambiguous IMO.
So why have a t/ directory at all? Put all the .t files into the top level
source, it'll be unambiguous that they're tests because of the .t! (Note:
rhetorical).
Its not just allowing the computer to figure out what's a test and what's not
but also the human.
I'm not sure I understand the concern about chdir(). Since use lib
is a compile time directive, then whether your code chdir()s at run
time or not seems to me to be a moot point. ??
use lib 't/lib';
chdir 't';
require Some::Module::In::t::lib;
lib.pm does not make the directory absolute, so it leaves your program
vulnerable to the above problem. Its rare you'd have to require instead of
use, some load order issues make it necessary, but it sure it annoying when it
happens.
A bit more common is this:
use lib 't/lib';
use MyTest;
chdir 't';
MyTest::do_something;
Where do_something() does something like require MyTest::OtherThing, to load
only on demand, which it now cannot find.
Yet-Another [cross-platform-compatible] possibility, which [TMK] works
around your cited chdir() issue is to do the following.
code
BEGIN {
use Cwd 'abs_path';
use File::Spec;
my ($vol, $dir) = File::Spec-splitpath(abs_path($0)); # use
script name to find t/
push @INC, $vol.$dir;
Even though it might happen to work, $vol.$dir is naughty. Reason #209809 to
use a module.
}
/code
Here it is much simpler, and going onto the front of @INC as it should.
use File::Spec;
BEGIN {
unshift @INC, map { File::Spec-rel2abs($_) } t/lib;
}
If I had to write all that code in every test I'd strangle myself.
Fortunately there's lib::abs which I'd thought I'd mentioned but must have
left it out. It handles all this for you. Though looking at the code it goes
through WAY more trouble than it should.
--
THIS I COMMAND!
Re: Test module for tests in Perl module distro
Michael G Schwern wrote:
Here it is much simpler, and going onto the front of @INC as it should.
use File::Spec;
BEGIN {
unshift @INC, map { File::Spec-rel2abs($_) } t/lib;
}
If I had to write all that code in every test I'd strangle myself.
Fortunately there's lib::abs which I'd thought I'd mentioned but must have
left it out. It handles all this for you. Though looking at the code it goes
through WAY more trouble than it should.
I take it back. lib::abs is misleading. It doesn't just turn relative lib
paths absolute as the name implies, it makes them absolute *to the location of
the current file* not the current working directory.
use lib File::Spec-rel2abs($dir);
and
use lib::abs $dir;
are not equivalent as I thought.
--
10. Not allowed to purchase anyone's soul on government time.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Test module for tests in Perl module distro
Guys, Let's say I have some common functions that I want available to all my .t files. So I've created a module that all the .t files can include. But where do I put it? I don't want to put it in lib/ because I don't want it to get installed, right? But when I put it in t/, make test can't seem to find it. I suppose I could include it via use t::MyTest; rather than use MyTest; but that seems like cheating. Plus then it means I'm tied to only running the tests from one certain directory (but maybe that's inevitable?). Is there a standard way of doing what I'm trying to do here? (Where standard could be defined as typical or best-practice or workable or whatever.) Or is there some reference that I've failed to read about building Perl modules (still working on my first CPAN upload) that would cover this? TIA. -- Buddy
Re: Test module for tests in Perl module distro
On Sun, Jul 5, 2009 at 9:40 PM, Buddy Burdenbarefootco...@gmail.com wrote: Let's say I have some common functions that I want available to all my .t files. So I've created a module that all the .t files can include. But where do I put it? I don't want to put it in lib/ because I don't want it to get installed, right? But when I put it in t/, make test can't seem to find it. I tend to see three variations. (1) put it in t/lib/MyTest.pm and use lib 't/lib' at the start of your test files (2) put it in t/MyTest.pm and use lib 't' at the start of your test files (3) either of the above but use t::MyTest rather than changing @INC with use lib... I don't think any one is much better than the others. I tend to like the t::MyTest approach from a readability standpoint because it's clear within the *.t file that this is a test library and it's clear where to locate it. -- David
