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.
> Indeed, parts are simpler: both the current skip() and the proposed
> todo() are a little misguided: they do not skip the test, that's up to
> you.
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.
> ### 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).
> 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.
> # 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.
> > Its advantage (aside from existing) is that you don't slow compilation
> > with lots of extra test code that Perl has to compile on every run.
>
> 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?
> 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.
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.
However, TMTOWTDI reigns supreme. Run with it!
