On Thu, Sep 14, 2000 at 12:01:03AM -0700, Glenn Linderman wrote:
> > Once extracted, a module can deal with it
> > just as easily, and with much more flexibility, than a core patch to
> > perl can.
>
> Who cleans up all the junk files later?
Nobody does, they're not junk. They go into the t/ directory of the
module/code distribution. More on that later.
> And if you have to extract them to use them, why bundle them in the first
> place.
Because its all done for you as part of "make test".
> > Besides, .t files aren't going anywhere and we'll still
> > need external (ie. MakeMaker) support to deal with them.
>
> Oh? I'm no QA guy, right? So I have no clue what a .t file is (sorry).
A .t file is simply a Perl program which outputs a series of "ok" or
"not ok" for each test run. Nothing more. They typically reside in a
t/ directory of a module's source code (that or there's one test.pl
file). Download any module from CPAN and have a look. A simple
example would be:
#/usr/bin/perl -w
print 2+2 == 4 ? "ok 1" : "not ok 1";
print 2*2 == 4 ? "ok 2" : "not ok 2";
When you run "make test" on a module it looks for test.pl and t/*.t,
runs them, and counts up the "ok"s and "not ok"s. Simple. Thre's no
plans to change this AFAIK.
So all RFC 183 needs changed is that when "make test" happens,
pod2tests would be run over each source file generating a .t file from
any embedded tests found (lib/Some/Module.pm's tests would go in
t/Some-Module-embedded.t) and the rest is as it is now. The .t files
are run and oks counted.
Simple, with a minimum of modification to the existing system.
Sorry if I took it for granted that people would understand the
testing system. And anyone for whom the above was new information, I
expect you FRONT AND CENTER at the "Writing Solid Perl" tutorial at
YAPC::Europe.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
MORONS!
