On Thu, Feb 15, 2001 at 08:16:01PM -0500, [EMAIL PROTECTED] wrote:
> On Thu, Feb 15, 2001 at 07:56:46PM -0500, barries wrote:
> > It's no more difficult to learn except for having to deal with closures.
>
> Closures are not an easy thing to learn. Trust me, I've been trying
> for the past few months.
Luckily, I'm not proposing confusing usages, you jus thave to stick any
my's above the call to do_all_tests. It's rather like Benchmark's
timethese() and cmpthese(), now that I think about it:
my $data_set ;
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 ) },
) ;
might output:
ok 1 - get_data_set
ok 2 - data_set_type
ok 3 - data_set_size
ok 4 - TODO elt_lengths
All that punctuation is ugly, whew. And I snuck in a syntax for
naming todo'd tests. One other factor is that skip()ing is not usually
a compile-time decision, so I don't think my previous skip => sub {...}
example is actually ythat useful.
Hmmm, but it would allow groups of tests, to, so you wouldn't need to
name *every* test, it could number tests like so
do_all_tests(
get_data_set => [
sub { $data_set = get_data_set() ;
ok( $data_set ) },
sub { ok( ref $data_set, "ARRAY" ) },
sub { ok( @$data_set, 10 ) },
todo => sub { ok( ! grep !length, @$data_set ) },
],
) ;
ok 1 - get_data_set.1
ok 2 - get_data_set.2
ok 3 - get_data_set.3
ok 4 - TODO get_data_set.4
> The current skip() is rather poor and that's going to be fixed.
> todo() should work exactly like ok() (other than the obvious bits)
> except that you can give it a reason.
Cool.
> > ### incorrect:> ok(frobnitz() eq 'HGLAG', 'frobnitz ok');
> > ok( frobnitz() eq "HGLAG", 1, "frobnitz" );
>
> Sorry, confusion there. That's my style of ok() I was using, not
> Test.pm's. Mine works as ok(EXPRESSION, NAME).
Ah, ok, thanks for splaining it! I figured you'd just dashed off the
message in pseudo code, but I wanted to be a little more literal to get
closer to apples and apples.
> > if ( $i_dont_feel_like_it ) {
> > ### incorrect:> skip("I don't feel like it");
> > skip( 1, 0, 0 ) ;
> > }
> > else {
> > ok( blather(), "blather result" ) ;
> > }
>
> The if/else logic is inevitable. The current skip() routine sucks, as
> noted. It should probably take one optional argument, a reason.
I agree--I had overlooked the need for runtime determination of that.
> > # ok( not_ready_yet(), "planned result" ) ;
> > > todo("I'll do it later"); # This line might work, but disagrees with
> > # the current behavior of ok() for "todo"
> > # tests, which whines on a true arg.
>
> Sorry, you're right. It would be todo(EXPR, REASON) under my system.
> Test.pm would do something more complicated. More on Test.pm next
> message.
I think we'd better keep EXPR out of todo(), for the same reason it
doesn't belong in skip(). A simple todo( "test name", "reason" ) might
be enough. If it's TODO, EXPR may blow up, especially as people do more
exception throwing.
> > You seemed to have missed the -nobloat option on the filter w/ subs
> > proposal, FWIW.
>
> Yeah, I did miss it. What is it and is it a Perl 6 mythical thing?
It was an option to the filters I was thinking out loud about that told
them to filter out test subs. So compiling
use autotest qw( -nobloat ) ;
sub foo_test {
...
}
without $ENV{AUTOTEST} would filter out all of sub foo_test. But I
like the POD proposals more, anyway.
> > Anyway, with a filter, test.pl might be unnecessary I think.
> >
> > perl -w %
> >
> > would do the trick. I'll try to scrape a prototype together for this
> > soon.
>
> I've found embedded tests are very useful for testing individual
> features as you declare them in the documentation, but for more
> complicated tests (such as checking interactions between various
> features or checking complicated features which require elaborate
> setup and checks) you still need a seperate testing program.
I'd say that all tests that test a single module can pretty much go
inthat module's source code. The examples and function/method unit
tests can be sprinkled throughout, but there's a lot of room at the
bottom of the module for a full test suite. In fact, for some patterns
of module interdependancy, often "higher level" modules can perform
broader tests than lower ones, leaving the t/ directory for really
complex scenarios and for contributed tests.
> Also, shoving alot of testing code into a library/program can cause
> the eye to trip over it. Makes quick scanning of the code logic a
> little more difficult because you have to examine it to differeniate
> between testing code and real code. Syntax highlighting can help
> some, but I've found in similar cases (such as having individual lines
> of code commented out) you get the same effect.
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. YMMV, of course.
> However, TMTOWTDI reigns supreme. Run with it!
Let's see, where's that bucket of tuits...
- Barrie
