Front page | perl.perl5.porters |
Postings from June 2013
On 6/29/13 10:58 PM, Craig A. Berry wrote: > On Jun 28, 2013, at 2:55 PM, Father Chrysostomos via RT<perlbug-followup@perl.org> wrote: > > 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. >> [snip] >> >> 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?). > > [snip] > > 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. > And that's a principle we should maintain to the greatest extent feasible. > 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 Well, that's a wound we've inflicted on ourselves (and whose severity is confirmed by the substantial number of "layers"-related tickets in RT). [...]and it's no longer a reasonable expectation to do parsing without loading modules. Still, I don't think we should abandon the principle. 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. > I say, "Please do that!" Thank you very much. Jim KeenanThread Previous | Thread Next