schwern,
Oh, hey, look: I never responded to this. <smacks self on nose> Bad coder. :-)
>>> One way to deal with this problem is to use the flexibility of TAP and
>>> eshew a testing library.
>>>
>>> print "1..1\n";
>>>
>>> ...run your code normally here...
>>>
>>> print $ok ? "ok 1\n" : "not ok 1\n";
>> Well, yes, but then I have to do all the redirection stuff myself.
> I think you misunderstand. You need a fresh process uncontaminated by
> any other library to run your test in. Each .t file is a fresh process
> over which you have nearly total control (enough for your purposes).
> Load the library and test it directly.
>
> $ cat t/doesnt_load_other_modules.t
> #!/usr/bin/env perl
>
> print "1..1\n";
>
> require My::Library;
> print !$INC{"Some/Other/Library.pm"} ? "ok 1\n" : "not ok 1\n";
>
> Done. Nothing else goes in that .t file. Straight forward Perl. No
> cross platform concerns.
Okay, I think what you're saying would work for _one_ of my problems.
But I actually have two concurrent problems:
* I need to compare the output from another Perl library with the
output from my library. (In this case it happens to be Data::Printer,
but I think that shouldn't matter.
* I need to collect the output from the other Perl library *without
loading it*, because I also want to make sure that my library loads it
for me.
Now, one strategy I could employ here is to put those two tests into
two totally separate .t files. That would work perfectly. But it
just seems messy to me ... like I'm cheating, somehow. I'm testing
two tightly coupled things:
# Does my library load the module?
# Having loaded it, does it use the module properly to produce the
expected output?
Those two things seem like they _ought_ to be two tests in a single
test file, not two separate test files just because I can't figure out
how to make Windows play nice. :-/
And I rather thought this would end up being a solved problem, that
lots of folks would have run into this previously. But I guess either
people haven't, or they haven't often enough to come up with a clever
workaround. So it looks like I have two viable options:
# Give up on the sensibleness of putting both tests into one test file.
# Give up on the convenience of avoiding making a temp file for the
script by using -e.
Neither one is _particularly_ attractive, but I think I'm going with #2 there.
(And thanks for making me spell this out; it's helpful in case I
really do decide to do a blog post.)
-- Buddy
