Front page | perl.perl5.porters |
Postings from June 2013
On Jun 28, 2013, at 2:55 PM, Father Chrysostomos via RT <perlbug-followup@perl.org> wrote:
> On Fri Jun 28 11:22:57 2013, craigberry wrote:
>> Not sure what the right fix is ... maybe move the test that uses
>> utf8.pm out of parser.t into a later test that knows where its
>> libraries are? And/or more aggressively poisoning @INC for the
>> core tests?
>
> The easiest quick fix would be to put:
>
> chdir 't';
> { local @INC = '../lib';
> ...
> }
>
> around the test. .
Right. There are plenty of patterns to follow for forcing a test to find libraries in the build directory tree. But I was less certain whether a test that now requires libraries should still be in t/comp/parser.t.
> But the same thing could happen very easily again when
> more tests are addedSimply moving the test to a new script in t/op/ doesn’t solve the latter
> problem.
>
> Maybe we do need TEST to pass -Ifoo. Or change the tests themselves to
> have the right @INC value (as most t/op/ tests do with their little
> preamble, that t/comp/require.t also has).
>
> Or, as you said, poison @INC, so that attempting to load utf8.pm will
> fail loudly.
>
> But I never feel comfortable with tests that sabotage part of perl to
> avoid relying on it in a test, because the tests are not testing
> anything that would happen in the real world. t/comp/use.t makes sure
> that feature.pm is not inadvertently loaded (why?).
The commit message has a reason but I don't know what the problem with versions was:
<http://perl5.git.perl.org/perl.git/commitdiff/2246ee039f9382f6a88766dc2e05a32de5ee2c3c>
> This has actually
> hidden bugs in the past (e.g., ‘no 6’ not working).
It's a fairly basic principle of testing that you test the more primitive parts without relying on the less primitive parts, whereas the "real world" assumes all the parts are working at the same time.
It seemed reasonable to me that one would want to test that the parser can parse input before worrying about whether loading modules is possible. But if merely evaling a character constant containing a non-ASCII character triggers an automatic load of utf8.pm, it may be that the layers are now too intertangled and it's no longer a reasonable expectation to do parsing without loading modules. I will add some library boilerplate to parser.t, but I thought I'd give folks a chance to say "Don't do that!" first.
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Thread Next