On Thu, Feb 15, 2001 at 11:34:46PM -0500, [EMAIL PROTECTED] wrote:
> On Thu, Feb 15, 2001 at 10:18:14PM -0500, barries wrote:
> > do_all_tests(
> > get_data_set => sub { $data_set = get_data_set() ;
> > ok( $data_set ) },
> > data_set_type => sub { ok( ref $data_set, "ARRAY" ) },
> > data_set_size => sub { ok( @$data_set, 10 ) },
> > todo => elt_lengths => sub { ok( ! grep !length, @$data_set ) },
> > ) ;
>
> Oooookay, what's the net gain here? What does all that mess buy you
> over just:
I don't think it buys anything, given your plans for noplan and todo().
I thought it did till I remembered the need for run-time determination
of skipping.
> However, you are right about explosive failure. So you can pass
> todo() a code ref...
>
> todo({ $obj->fooble == 42 });
Cool. is that a HASH ref
> and todo() will run that in an eval block.
>
> > Again, putting the test suite at the bottom is still useful (to me). I
> > tend to bounce back and forth between the code under test and the test
> > suite as bugs surface or I get an idea for a new test.
>
> This defeats the purpose of embedded tests.
Not really: in the same file is closer than in some other file over in
another directory. So there's a...
> Better chance you'll keep it up to date.
especially if you do the
> As for rapidly going between the tests and the code, you just pull up
> the test file in one window/frame and the code file in another.
Understood, but in the same file is still closer (to me). For instance,
renaming an API, one global replace does the trick. And nobody need
guess or remember the correspondence between .t file names and .pm file
names and locations. This is way down in the YMMV zone, I'm not arguing
correctness here, just explaining my preference as a Test user and
likely Pod::Tests user to the most active maintainer of them.
> Hmmm... how would your embedded tests get run as part of a standard
> MakeMaker "make test"?
They do get run via test.pl in my current environment.
> I realized a few months ago that even if I do
> patch MakeMaker do to something cool, I can't rely on it because my
> code has to work on older installations.
What about providing a module that wraps both Pod::Tests and
Test::Harness, scans the command line and tests any specified modules?
If no command line arguments, then all files under lib that contain
the string /^\s*use selftest\b/ would be tested. Actually, it should
probably take an option to make it scan blib when called from the
Makefile.
The resulting test.pl would look like:
use selftest::Harness ;
selftest::Harness->exec( @ARGV ) ;
So, if an author/maintainer is shipping code that uses the selftest filter,
they can provide a trivial "stock" test.pl.
> I suppose you could do the same, but it will
> require compiling the code to do it.
I like the thought that selftest is just a wrapper around Pod::Tests.
That makes it your problem :-).
- Barrie
