"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"
Is there a reason the output has to be created during testing rather
than being part of the distribution? What about running it out in a .t
file which precedes the .t file in question?
Daniel
On 29/01/2013, Buddy Burden <barefootco...@gmail.com> wrote:
> 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
>
