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!
