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