(This somehow accidentally drifted off list)
On Wed, Mar 14, 2001 at 09:44:15AM -0500, barries wrote:
> I tmeans that I was up too early... What I should have said was that
> you could then do
>
> use Testing ;
>
> ok 1 ;
Is C<use Testing noplan;> so much more work? I'd really like to force
a conscious decision to go with no plan.
However, with your exit strategy, Test::Harness already checks for
abnormal exits (I'll double check that a non-zero exit is explicitly
considered a failure). So no need for the final comment to be
anything magical.
> > I'd have expect() work like this with references:
> >
> > # If one's a reference and one's not, that's false.
> > if( ref $this xor ref $that ) {
> > return 0;
> > } else {
> > return $this eq $that;
> > }
>
> Why the if-else? Shouldn't $this eq $that be the right thing in either
> case?
my $ref = {};
expect( $ref, "$ref" );
They are not the same. Its not uncommon to accidentally stringify a
reference, and I'd like to catch that. Or doing something like
thinking hash keys can hold references.
> > There has to be a routine that just tests for a true expression.
> > However it doesn't have to be ok(). It could be... true() and
> > false()? is() and isn't()? (I like that one) be() and not2be()?
>
> s/and/or/g => "That is the question". I like is() and isnot() or
> is_not().
Awwwwwww, not isn't()? ;) I'd probably go with isnt() just because its
shorter.
> Stray thought: test names must match /\D/ or output will be too
> confusing.
Good thought. Maybe it'll just be a warning.
> Lessee, aiming for simple, flexible API with minimal typing, sq.
> brackets indicate optional args, not ARRAY ctors:
>
> pass [ $test_name ] ; # replacement for Test's ok( 1 )
> fail [ $test_name ] ; # replacement for Test's ok( 0 )
> ok_if $cond, [$test_name] ; # replacement for Test's ok( $cond )
> is $x, $y, [$test_name] ; # a lot like ok( $x, $y ) is today
> is_not $x, $y, [$test_name] ; # a lot like ok( $x ne $y ) is today
>
> I like is() and is_not() for several reasons: they're more sensical than
> ok( $x, $y, $comment ) is, they allow complete backward compatibility with
> today's Test.pm, and they're short. I've always wanted a way of doing
> not_ok( $x, $y ), and is_not( $x, $y ) ; makes sense.
is() and is_not (or isnt() or isn't(), dunno) sound good.
pass() and fail()... yeah I guess so.
ok_if() is too wordy for something so common. Keep it ok() and see below.
How about is_like() for regexes? or like()?
like($x, qr/$y/, [$test_name]);
(Perhaps long with sorta() using String::Approx and yaknow() using ESP.pm ;)
> We could allow ok($cond) for backwards compatibility, I suppose.
I can't do complete backwards compatibility with Test::ok(). Its too
weird, too undocumented and too good a name not to use.
But we've got to provide some way to ease the switch over from Test.
Maybe provide a C<use Testing plan tests => 42, ok_like_Test => 1> and
it will export an ok() that behaves as close to Test::ok() as I can
figure out.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
please remove your pants
we promise this won't hurt much
prepare for insertion
-- Fmh
