On Sat, 17 Mar 2001, Paul Johnson wrote:
> On Sat, Mar 17, 2001 at 05:20:23PM +0000, Piers Cawley wrote:
> > Michael G Schwern <[EMAIL PROTECTED]> writes:
> >
> > > Ok, that's great. But then Piers Cawley cried out "HALTING PROBLEM!"
> > > from the front row (and get your feet off the stage).
> >
> > My heckles have always been of the highest quality.
> >
> > > > From: Piers Cawley <[EMAIL PROTECTED]>
> > > > Subject: Re: [FWP] Stumper
> > > > To: Michael G Schwern <[EMAIL PROTECTED]>
> > > > Cc: [EMAIL PROTECTED]
> > > >
> > > >
> > > > Isn't this a halting problem issue?
> > > >
> > > > foo { bar() if bar() && bar() };
> > > >
> > > > How many times does bar get run?
> > >
> > > To which my reply is basically, "Oh crap."
> >
> > Ah well, better to find the problem early.
>
>
> ok()
>
> May I propose the following interface?
>
> ok($scalar, $test_name, $reason);
>
> I suspect that the semantics are fairly obvious. If $scalar is true the
> test passes, otherwise it fails. $test_name needs no explanation, and
> it need not be present. $reason is ignored if present. It is only
> there to match todo() and skip(). Details below.
>
> My motivation for this simple interface is that I see little benefit to
> me as a module author in being able to write
>
> ok($x, 17);
>
> rather than
>
> ok($x == 17);
>
> If anything, the latter is more explicit. Think of it as removing all
> special cases :-)
This is fine but the 2 arg version allows the test module to tell you
*why* the two args did not match. One of the useful features of the test
module is that it tells you both $x and 17 when they are not equal so that
you can see the resaaon for the failure without having to add a print
statemtnt to the test. The single argument ok() will just tell you a
failure but not what the failure was.
> >
> skip()
>
> Using the same interface as ok() and todo(), skip() skips the test for
> $reason. If $reason changes (eg Windows supports file locking) the test
> can just change to ok(). If it changes from skip() to todo(), $reason
> may need to be changed, but if it wasn't it would probably still be
> somewhat appropriate.
>
I think the skip() function should at least add "Skip" to the reason when
printing it - the user of Test.pm should not need to know the format of a
skip message required by Test::Harness.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj