Ah... I read the "does it work" literally as a question. Thanks. I haven't used nmake in quite a while. Bless you for the example.

It is indeed only a matter of setting @INC for tests. At least at this stage, I don't forsee ever needing support libraries for anything but testing.

In truth, I had already considered using "test.pl" to set lib and run my scripts. That certainly avoids splatter.

It should have been a three liner (lib, File::Find, Test::Harness::runtests). It worked like a charm when I typed perl ./test.pl on the command line. However, when that same test.pl file was run through "make test" the TAP output never made it to Test::Harness.

I only investigated it superficially, but near as I can tell, it likely had something to do with ExtUtils::MakeMaker::test_harness. It passes test.pl to Test::Harness::runtests. That call of runtests within runtests was probably not something for which Test::Harness was designed.

I quickly concluded that if I couldn't run my tests through runtests, I'd be handcrafting a test runner much like the example you posted. I'd have to study Test::Harness to find out exactly why TAP output is getting swallowed when calls to runtest are nested. Then I'd have to emulate runtest in a way that does not cause that problem.

Then again maybe the solution is much less complex? Perhaps it is nothing more than redirecting or duping STDOUT during test.pl's call to runtest and then dumping that output to STDOUT so that the outer call to runtest saw what it needed? Either way, it is time spent researching and experimenting.

At that point I decided that this was turning into a real programming task and thought it was fair to ask: how important is this really?

Doing it isn't the hard part. Spending my free time all but reinventing the wheel when the need for it seems to be more emotional than practical is what I'm having trouble stomaching. I know there are times when satifying the emotional is important. But its my emotions and time too. I need a good reason.

That's why I posted this: if it really is all that important, I wanted concrete reasons. What I got was "you're a terrible programmer for even wanting to not splatter" and "you're really dumb if you don't realize passthru to Module::Build is crap". Very helpful.

...Doing it isn't the hard part. Spending my free time all but reinventing the wheel when

Or you could have asked how to do it, instead of trawling (fishing) for "concrete reasons" ... :)

See another example http://search.cpan.org/~evo/Class-MakeMethods-1.01/test.pl, the magic part is naming it "tests/*t" instead of "t/*t", works like a charm, there is no TAP swallowing or anything :)

I had been already to break out the Champagne when I cleaned out everything and rebuilt from scratch. Once again, even with all the tests in tests rather than t, I saw the same behavior. test.pl runs fine when it runs directly on the command line perl ./test.pl. TAP gets swallowed when test.pl is executed by make test.

Clearly whatever is causing this on-again off-again TAP swallowing is not merely about the name of the test directory. In fact it seems to have nothing to do with it. You can get make test to work with the files in t or in test. The only factor that seems to make a difference is the "test" key:

# this creates a broken Makefile
WriteMakefile
(
 'INSTALLDIRS' => 'site',
 , 'NAME' => MyModule::Foo
 , 'VERSION' => 0.999_003
 , 'PREREQ_PM' => { 'Fiddle::Faddle' => 0 }
 , 'test' => { TESTS => 'test.pl' }
);

# this does not (test key removed)
WriteMakefile
(
 'INSTALLDIRS' => 'site',
 , 'NAME' => MyModule::Foo
 , 'VERSION' => 0.999_003
 , 'PREREQ_PM' => { 'Fiddle::Faddle' => 0 }
);
[download]

I'm not going to be entirely comfortable until I understand why this makes a difference. Just as yours and my empirical observations about t vs. tests turned out to be unlikely, so too could my empirical observations about the 'test' key.

It does however look like we are well on our way, without having to reinvent the wheel.

As for "you could have asked" :-).... don't underestimate your role in causing me to revisit an option I'd rejected. By believing it could be done and even offering to look at a reduced code sample, you convinced me that I might have given up too quickly. You all but invited me to ask for help - and you are correct that I did not explicitly do so - it isn't easy for me - I tend to believe I have to take care of myself at all times. However, had you not issued that quasi-invitation, I would not have told you the story of why I gave up and perhaps you would not have offered evidence that my original intent to call runtests could work if things outside my test.pl code were set up properly.

Thanks again for your help. You do honor to the name "Anonymous Monk".