Re: Test Script Best-Practices
On Jan 27, 2006, at 6:06 PM, James E Keenan wrote:
Steffen Schwigon wrote:
Quite often -l (to read from lib/) is enough, depending on your
module
build complexity. For -b you have to call ./Build before prove,
which can be annoying and/or difficult to remember.
I'll have to try that out. My modules all use MakeMaker rather
than Module::Build. And I'm generally using 'prove' to trouble-
shoot individual tests after I've already run 'make test' and
identified which test files have failures.
For modules that are in {src_dir}/lib/ I have often had my
individual .t files do this:
use FindBin qw($Bin);
use lib $Bin/../lib;
I often have a situation which probably doesn't come up for most Perl
developers - I usually develop these days using the EPIC plugin for
Eclipse, and it doesn't have an easy way to execute 'prove' or 'make
test', but it can execute Perl scripts in my source directory, so, it
is useful for me to be able to have each .t file be executed by a
process whose $PWD might be outside the source directory. Usually I
use a little script 'run_tests.pl' that basically does what 'prove -v
t' does, and have Eclipse execute that. The run_tests.pl script uses
FindBin so it knows where lib/ and t/ are.
Re: Test Script Best-Practices
James E Keenan [EMAIL PROTECTED] writes: Tyler MacDonald wrote: The convention in running tests is to use the 'prove' command; prove t/01_class.t That should take care of blib for you. Not quite. You need to call the -b option to get prove to read from blib. When I've been revising one of my already installed modules I've gotten burned by failing to explicitly call: prove -b t/01_class.t Quite often -l (to read from lib/) is enough, depending on your module build complexity. For -b you have to call ./Build before prove, which can be annoying and/or difficult to remember. Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: Test Script Best-Practices
Steffen Schwigon wrote: Quite often -l (to read from lib/) is enough, depending on your module build complexity. For -b you have to call ./Build before prove, which can be annoying and/or difficult to remember. I'll have to try that out. My modules all use MakeMaker rather than Module::Build. And I'm generally using 'prove' to trouble-shoot individual tests after I've already run 'make test' and identified which test files have failures. jimk
Re: Test Script Best-Practices
James E Keenan wrote: Steffen Schwigon wrote: Quite often -l (to read from lib/) is enough, depending on your module build complexity. For -b you have to call ./Build before prove, which can be annoying and/or difficult to remember. I'll have to try that out. My modules all use MakeMaker rather than Module::Build. And I'm generally using 'prove' to trouble-shoot individual tests after I've already run 'make test' and identified which test files have failures. jimk Or $a_specific_perl_path Build in the case of other situations. Adam K
Re: Test Script Best-Practices
Tyler MacDonald wrote: Jeffrey Thalhammer [EMAIL PROTECTED] wrote: [snip] * When run outside of 'make test', should the test script force modules to load from the distro's lib or blib directory by default? Or should it just load from the user's existing @INC (whatever it may be). The convention in running tests is to use the 'prove' command; prove t/01_class.t That should take care of blib for you. Not quite. You need to call the -b option to get prove to read from blib. When I've been revising one of my already installed modules I've gotten burned by failing to explicitly call: prove -b t/01_class.t (Additional note: I like to see the test messages, so 99% of the time what I actually call is: prove -vb t/01_class.t) See 'perldoc prove'. Jim Keenan
Test Script Best-Practices
Greetings,
I've noticed that CPAN authors use a variety of
techniques to manipulate the run-time environment in
their test scripts. Usually, it involves changing
directories and/or altering @INC. This one seem pretty
popular:
BEGIN {
if($ENV{PERL_CORE}) { #What is PERL_CORE?
chdir 't';
@INC = '../lib';
}
else {
unshift @INC, 't/lib';
}
}
Or sometimes you see this:
use FindBin $Bin;
use lib $Bin/../lib;
On the other hand, some test scripts have no such
code, thus relying on the user (or the Makefile) to be
in the right directory and setup @INC so that the
right modules are loaded (e.g. perl -Ilib
t/test_scrpt.t). So what do you suggest for
best-practices here? Specifically...
* Should a test script have a shebang? What should it
be? Any flags on that?
* When run outside of 'make test', should the test
script force modules to load from the distro's lib or
blib directory by default? Or should it just load
from the user's existing @INC (whatever it may be).
* Should a test script make any assumptions about the
CWD? Is it fair/safe for the test script to change
directories?
* What's the best practice for testing-only libraries?
Where do they go and how do you load them? Is there
a naming convention that most people follow (e.g.
t::Foo::Bar).
Thanks.
-Jeff
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Test Script Best-Practices
On Tuesday 24 January 2006 18:53, Jeffrey Thalhammer wrote:
Greetings,
I've noticed that CPAN authors use a variety of
techniques to manipulate the run-time environment in
their test scripts. Usually, it involves changing
directories and/or altering @INC. This one seem pretty
popular:
BEGIN {
if($ENV{PERL_CORE}) { #What is PERL_CORE?
chdir 't';
@INC = '../lib';
}
This is necessary for core modules. Checking PERL_CORE (which Perl's make
test sets) makes dual-life modules easier to test. When running as part of
Perl's make test, these tests must rely on only the currently-built Perl.
else {
unshift @INC, 't/lib';
}
}
I think this is rather:
unshift @INC, '../lib';
Otherwise, the tests for dual-life modules won't find necessary libraries
under t/lib.
* Should a test script have a shebang? What should it
be? Any flags on that?
It's probably immaterial, unless you run test scripts without invoking Perl or
prove somehow. (Not likely.)
* When run outside of 'make test', should the test
script force modules to load from the distro's lib or
blib directory by default? Or should it just load
from the user's existing @INC (whatever it may be).
I used to do this to make my life easier, but now I think it's just noise that
looks too much like the ol' black magic header that Perl tests used to have.
Use prove.
* Should a test script make any assumptions about the
CWD? Is it fair/safe for the test script to change
directories?
It's absolutely fair. Unless you use absolute paths (and you'll likely have
to set them in the tests during the configuration process), the important
parts of @INC contain relative paths.
* What's the best practice for testing-only libraries?
Where do they go and how do you load them? Is there
a naming convention that most people follow (e.g.
t::Foo::Bar).
Do you mean Test::Class based libraries or common testing routines? The
former, I say name Foo::Bar::Test and install them with the other modules if
there's even a remote chance that someone might subclass your code. (Non-OO
modules don't bother.)
Common testing routines, I stick under t/lib and don't namespace. It could be
clearer if you do, but it's a matter of whatever makes your test files more
maintainable.
-- c
Re: Test Script Best-Practices
Jeffrey Thalhammer [EMAIL PROTECTED] wrote: * Should a test script have a shebang? What should it be? Any flags on that? It's not at all neccessary, but IMHO it is good form; it's a surefire way for anything else (HTTP server, IDEs, etc) to figure out that you're actually a perl script and do the right thing (run it, syntax highlight it, whatever). For test scripts and other executables, I use: #!/usr/bin/perl For .pm files, I just put #!perl * When run outside of 'make test', should the test script force modules to load from the distro's lib or blib directory by default? Or should it just load from the user's existing @INC (whatever it may be). The convention in running tests is to use the 'prove' command; prove t/01_class.t That should take care of blib for you. * Should a test script make any assumptions about the CWD? It's expected that a test script will be executed from the package's root directory, where the Makefile.PL etc reside. Is it fair/safe for the test script to change directories? Yes. Typically, each test script runs as it's own process, so if it changes directories, it only affects that one test file and not the others. It would probably be nice of the test script to only change to directories inside it's packages root, as opposed to snooping around the harddrive of whomever is doing the testing. * What's the best practice for testing-only libraries? Where do they go and how do you load them? Is there a naming convention that most people follow (e.g. t::Foo::Bar). I don't know. If there is that could be far more convienent than what I do. I usually use My::Package::Test::blah. - Tyler
Re: Test Script Best-Practices
Jeffrey Thalhammer wrote:
* Should a test script have a shebang? What should it
be? Any flags on that?
I often see -t in a shebang. One downside of the shebang, though, is
that it's not particularly portable. As chromatic said, with prove
it's not really necessary. (prove -t)
* Should a test script make any assumptions about the
CWD? Is it fair/safe for the test script to change
directories?
Anything that affects the file system (particularly creating directories
and files) often needs to change directories as part of the test.
As a side note, I wrote File::pushd to make it easy to change
directories locally in a block and then snap back to where one started.
I find it handy for that kind of testing.
use File::pushd;
{
my $dir = pushd( $some_dir ); # change to $some_dir
# do stuff in $some_dir directory
}
# back to original directory here
# convenient for testing:
{
my $dir = tempd; # change to a temp directory
# do stuff in temp directory
}
# back to original directory and temp directory is gone
* What's the best practice for testing-only libraries?
Where do they go and how do you load them? Is there
a naming convention that most people follow (e.g.
t::Foo::Bar).
I've personally come to like the t::Foo::Bar style as it is
immediately obvious that the module in question is test-related. It's a
handy affordance.
Regards,
David Golden
Re: Test Script Best-Practices
On Tue, Jan 24, 2006 at 10:25:44PM -0500, David Golden wrote: Jeffrey Thalhammer wrote: * Should a test script have a shebang? What should it be? Any flags on that? I often see -t in a shebang. One downside of the shebang, though, is that it's not particularly portable. As chromatic said, with prove it's not really necessary. (prove -t) -T or -t in a shebang tells Test::Harness or perl's TEST that perl needs to be run with that switch for the tests to test what they are supposed to test.
