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
