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 Schwern<schw...@pobox.com> wrote:
> David Golden wrote:
>> On Sun, Jul 5, 2009 at 9:40 PM, Buddy Burden<barefootco...@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?
>
