On Tue, Feb 20, 2001 at 10:38:43PM +0000, Piers Cawley wrote:
>
> I like this, but I'm not sure it really goes far enough.
I'm leaning against the do_all_tests() concept as an over-reaction to
the current state of the art, where you gotta count all those tests
yourself. More below, but what I'd really like is the minimalist:
- noplan() ; ## a lá schwern
- skip( $what_and_why ) ;
- ok( $boolean ) ;
- ok( $got, $expected, [ $test_name ] ) ;
- todo( $boolean ) ; ## simpler than schwern's todo( \&test, ) ;
- todo( $got, $expected, [ $test_name ] ) ;
The lack of noplan() and todo() is why I meandered into the
list-of-CODE-refs approach.
Now, as to why I think what's above is too complicated given noplan(),
a simpler skip(), and todo():
The skip => functionality I proposed above is limited since it can't
handle the case where you don't know to skip something until after a few
tests have already gone by, and more often it would look like
my $skip_foo = check_for_skippiness() ? "skip" : "do" ;
do_all_tests(
$skip_foo => sub {
};
) ;
But that's a bit of an awkward syntax, IMHO, compared to the wordier but
more prosaic and obvious:
if ( check_for_skippiness() ) {
skip( "skipped testing foo because ..." )
}
else {
ok( foo, 1, "foo" ) ;
}
I dislike lack of obvious flow of control in the do_all_tests() concept,
and it forces you into closure-land if you need to carry state from one
state tot he next (which I do frequently, but would prefer not to foist
on others. Closures are pretty simple once you "get" them, but it's a
mind-shift that can be difficult to make).
I don't much like the todo{...} schwern proposes since it's unlike ok()
and skip(), and leads to easily into closure land, I just want a todo()
that looks like ok() so it's a one word edit to claim a feature's been
implemented.
> I do like the
> idea that it has where you just have to declare a bunch of methods of
> the form test_foo and the Test::Unit::TestSuite superclass will use
> that to build the list of tests to be run.
I like the idea too, and am right now I'm working with a bunch of Perl
objects encapsulating database queries where an object can have a class
method tests() that can be called by test.pl, which then executes the
tests, kinda like an inside-out do_all_tests(). It leads to
closure-land and other trickiness, so I'll be switching to use SelfTest
on those objects from now on, especially once noplan() makes it into
Test::Harness.
The ability to run my embedded tests easily from the command line (using
the test.pl I mentioned above) has been a real boon to me. SelfTest
provides a nicer way than test.pl, I think. A simple <Alt>-F9 saves my
file and runs it through the wringer in a subshell. I save and test
after almost every change just to make sure I haven't dropped a brace or
something.
<...neat expansion on do_all_tests() concept snipped...>
> Well, it's a thought anyway.
Seems pretty cool, but I'm trying to perceive the advantage over a pure
sequential/functional. I think I'm asking for an example where this
adds significant benefit.
- Barrie
