Sometimes I wish the @INC paths had "same directory as the main script" option!

I think I've done something like this before. The following is untested:

BEGIN {
  use File::Basename;
  my $dir = dirname(__FILE__);
  unshift @INC, $dir;
  require MyModule;
}
[download]

I thought about that before writing the code, but since I'm specifically testing the use statement itself, I didn't want to "fake it" or alter it in any way. That's why I have separate files at all instead of just putting them into the test script.

Good point about using __FILE__. I kind of forgot about that, but use $0.

—John

That makes the test file sensitive to what directory its run from.

True, but I don't find this a huge problem myself.

I tend to run tests using make test, so ExtUtils::MakeMaker figures it out for me.

If I want to run individual tests from the command line it's easy to add the path in with -I, or use a tool like Test::Verbose (which looks like it needs patching for Win32 - so probably not a lot of use for you :-).

My test file, now named t/test.t, by default prints the "ok" lines (only) for the benifit of Test::Harness. But I can run it with the -verbose switch to get trace statements and dumps of structures so I can see what's happening, or with -quiet which just gives me a one line "all tests passed" (or the fail statements). So when developing, I run t/perl test.t -verbose. Turns out the makefile runs Test::Harness from the same directory (that contains the makefile) anyway, or maybe it's whatever the current directory was without changing anything specifically. So my quick and dirty solution is to add 't' to the @INC if it exists, and if not it assumes its being run from its own directory. Hmm, will perl complain about things in @INC that don't really exist? Maybe I could skip the conditional.

I seem to remember a module that gets the script's directory, for just such a purpose. Maybe I'll find that.

—John

I've just had a quick look at your test.t from Exporter-VA-1.2.3. Annoying comments/suggestions follow. Feel free to ignore :-)

I would strongly consider using Test::More and Test::Builder. It handles all the book keeping on test headers, footers and exit values for you. Implementing verbose and vv with Test::Builder is trivial.

You don't need the "#" after the "ok" and "not out" outputs. Currently the "#" character is used to indicate special kinds of test failure/success ("# skip" & "# TODO" tests). While Test::Harness copes happily with the "#" in other circumstances I would avoid it unless you are dealing with one of these special cases - just for the sake of clarity.

Consider testing the environment variable TEST_VERBOSE as well as your -verbose flag. That way you can do make test TEST_VERBOSE=1 to get your debug code.

The case when the code passed to verify dies should cause a failed test, rather than a printed error message. Conceptually the test (does this code produce this result) has failed.

Matter of personal style, but I would do:

{ package C1; use M1 v1.0 qw/--verbose_import &foo bar baz quux bazola
+ $ztesch --dump/ }
verify "C1::foo (5)", "Called M1::foo (5).";
...
[download]

instead of

package C1;
use M1 v1.0 qw/--verbose_import &foo bar baz quux bazola $ztesch --dum
+p/;
sub verify;
*verify= \&main::verify;
verify "C1::foo (5)", "Called M1::foo (5).";
...
[download]

to save having to alias verify into each module.

I seem to remember a module that gets the script's directory, for just such a purpose.

You're probably thinking of FindBin - which is broken.

Perl doesn't complain about nonexisting directories in @INC, no.

You could check for the existence of your test modules with something like -f "./$foo" or -f "t/$foo" and bail if you can't find either.

Makeshifts last the longest.