On Wed, Mar 14, 2001 at 01:38:01PM +0000, Michael G Schwern wrote:
> On Wed, Mar 14, 2001 at 07:45:29AM -0500, barries wrote:
> > > I'd like to alter what Test::Harness accepts as little as possible,
> > > more in the interest of keeping the harness rules simple than anything
> > > else. Wedging test names in will be difficult enough.
> >
> > That was just so you could not plan at all, not even to "no_plan".
>
> What does that mean, exactly?
I tmeans that I was up too early... What I should have said was that
you could then do
use Testing ;
ok 1 ;
and the output would be like
ok 1
# Test script exiting normally
and Test::Harness would see that everything was normal.
On the other hand, if the test script died early, the lack of a plan and
the lack of the final line would cause Test::Harness to complain.
>
> > > expect ($this, $that, $test_name);
> > > expect_qr($this, qr/that/, $test_name);
> > >
> > > I like that better. I know its rare to test for equality between two
> > > regex references,
> >
> > Extremely rare.
> >
> > > but someone's going to complain about it.
> >
> > They can expect( "$this", "$that", $test_name ) ;
>
> 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?
> No, its got to fail. Fortunately, Aegis doesn't know about todo
> tests. So it will see the "not ok 42 # todo" and just think its a
> failure. (Actually, we have a home-rolled harness around the tests.
> Aegis just cares if the script exits 0 or 1).
Thanks for the splain.
> > Very rare case, and the stringification trick addresses it. Much more
> > common, IMHO, to look for shallow equality (same contents, not
> > necessarily same places in memory).
>
> Implicit, quiet magic in interpreting if a test succeeded or failed
> makes my feet itch.
Yeah.
> It encourages tests like:
> ok( $obj->is_foo, 1 );
See your point.
> 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().
Stray thought: test names must match /\D/ or output will be too
confusing.
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
We could allow ok($cond) for backwards compatibility, I suppose.
Without it, though, the calls with the shortest sub names are the most
self-documenting calls. Not sure I see the need for pass/fail, but
they're cute. Could call nok "not_ok".
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.
- Barrie
