On Tue, Mar 06, 2001 at 09:28:31PM +0000, Michael G Schwern wrote:
>
> BEGIN { plan tests => $Num_Tests }
> # or
> BEGIN { noplan }
> # or
> BEGIN { skipall }
You may want to settle on using underscores everywhere or nowhere in the
interests of consistency.
Perhaps it would be a tad easier to assume noplan if there's no plan
call present. Then Test::Harness would complain about not seeing
output.
Perhaps this would work if noplan emitted a line at the end like "Test exiting
after $Num_tests\n" or something and Test::Harness whined if that line
were not present. It's only a line of code, so no big deal.
> # Various ways to say "ok"
> ok($this eq $that, $test_name);
>
> expect($this, $that, $test_name);
> expect($this, qr/that/, $test_name);
Thank you for preserving qr/foo/ and not '/foo/'.
> skip($why, $test_name);
>
> todo($why, {$this eq $that}, $test_name);
s/{/sub {/ ; # sub-avoidance only works in first parm, IIRC:
sub f($&) {
print join",",@_,"\n" ;
}
f(a,{++$b}) ;
^D
Type of arg 2 to main::f must be block (not scalar ref constructor) at - line 4,
near "}) "
> todo_expect($why, $this, $that, $test_name);
> todo_eval($why, sub { $this->that }, $test_name);
Perhaps fold todo_eval into todo_expect? Also, what's the advantage of
using the word "sub" instead of the word "eval"? Seems clearer to me to
KISS the API and let the user type "eval" instead of "sub", but I
haven't played with it yet.
todo_expect($why, eval { this }, $that, $test_name);
Hmmm, howabout using a modifier function that ok() and expect() see that
change it's behavior:
package Testing ;
sub todo($) {
return bless shift, "Testing::todo_why" ;
}
then in the test suite:
ok( todo "not implemented yet", $result, $test_name ) ;
expect( todo "not implemented yet", eval { $this }, $that, $test_name ;
so converting todo's to full tests is a simple act of deletion.
Hmmm, turning that around, perhaps:
package Testing ;
my $in_todo ; # Globals to let ok(), expect() know they're in a todo
my $todo_why ; # and why they're in it
sub todo (&$) {
my ( $func, $why ) = @_ ;
croak "No reason given for todo." unless defined $why && length $why ;
local $in_todo = 1 ;
local $todo_why = $why ;
eval { $func->() } ;
return print "ok ... # TODO $why\n" if $@ ;
}
Then todo-ing a test might look like:
todo {
ok( .... ),
} "why" ;
I had to require $why in the prototype to force an error if a user puts
a comma after the } in that type of example.
Just some thoughts...
> # Utility comparison functions.
> eqarray(\@this, \@that);
> eqhash(\%this, \%that);
> eqset(\@this, \@that);
How deep are these equality operators? It'd be happy to see these done
quietly by expect(), to keep the API simple. So if expect sees two refs
of the same type passed in, it would deep-compare them, for some def of
deep. I think
expect( \%this, \%that, $test_name ) ;
works ($test_name to be optional for me) well in a DWIMMERLY fashion.
> =head1 DESCRIPTION
>
> This module takes some of the drudgery out of writing test scripts by
> providing utility functions and handing the numbering and output
> formatting for you.
>
> So instead of writing:
>
> print $this eq $that ? "ok 1\n" : "not ok 1\n";
>
> You can say:
>
> ok( $this eq $that );
or, more likely
expect( $this, $that ) ;
since the latter gives better diagnostics.
> =head2 Test names
>
> By convention, each test is assigned a number in order. This is
> largely done automatically for you. However, its often very useful to
> assign a name to each test. Which would you rather see:
>
> ok 4
> not ok 5
> ok 6
>
> or
>
> ok 4 - basic multi-variable
> not ok 5 - simple exponential
Please don't forget to print the caller's file and line here. Might
also be cool to allow the test program to set a "confess" flag that
gives you stack dumps for failing tests, I have cases where ok() is
buried inside a utility sub and thus it's hard to tell what file and
line the croak is on.
> ok 6 - force == mass * acceleration
>
> The later gives you some idea of what failed. It also makes it easier
> to find the test in your script, simply search for "simple
> exponential".
Hmmm, should testing warn if you give the same name to two tests?
> ok($this eq $that);
> ok($this eq $that, $test_name);
This is implicitly promoting the call with lower diagnostic value.
Hey, howabout Huffman coding the API so the more useful, presumably more
used, call is shortest:
ok( $this, $that, $test_name ) ;
test_assert( $this eq $that, $test_name ) ;
Also continues the tradition of ok()ing things for most tests.
- Barrie
