Front page | perl.perl5.porters |
Postings from November 2003
On Thu, Nov 13, 2003 at 04:37:41PM -0800, Ilya Zakharevich wrote:
> On Thu, Nov 13, 2003 at 04:06:52PM -0800, Michael G Schwern wrote:
> > > ./perl t/op/stat.t
> > >
> > > to provide as small "Perl-related environment" as possible. E.g.,
> > > consider line-ending bugs; if
> > >
> > > ./perl t/TEST op/stat.t
> > >
> > > fails, I do not know whether I should debug t/TEST, or t/op/stat.t.
> >
> > You can do
> >
> > ./perl -MTestInit op/stat.t
>
> Same difference. This brings in possible bugs in TestInit.pm.
Its interesting you chose stat.t. This uses Config, File::Spec and test.pl
which in turn use more modules. In the end, stat.t loads nine modules
totalling 2381 lines of code (not including all the code in stat.t)
This is pretty typical for an op test.
TestInit.pm would add 7.
Let's keep things in perspective here.
> Let me summarize: I think that at least some "basic" set of
> functionality should be tested without reliance on TestInit. Most
> probably having boilerplates left in t/{base,run,op,comp,io} is
> enough. The rest can be required to run with TestInit.
I'd reduce that to just base and comp. All the rest are already allowed to
require test.pl and use modules like Config.pm and File::Spec. TestInit
isn't going to make a dent.
The last trick is having the tests find TestInit.pm. Some folks run tests
from the top of the source tree, some from inside t. It would be nice if
we didn't have to put logic for figuring this out in each test. So a
very simple solution is to link/copy perl-src/t/TestInit.pm to
perl-src/TestInit.pm as part of test_prep and minitest. That way
"use TestInit" will work in both places.
With each test saying "use TestInit" this
./perl t/op/stat.t
will work same as before. So will
./miniperl t/op/stat.t
This is something I'd be overjoyed to code up.
--
Michael G Schwern schwern@pobox.com http://www.pobox.com/~schwern/
I'm exploring my nipples.
Thread Previous
|
Thread Next