On Wed, Mar 14, 2001 at 03:22:26PM +0000, Michael G Schwern wrote:
> (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'm cool with that, it was a thought I was trying to communicate
accurately, not necessarily a good thought :-).
>
>
> > > 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.
I think this is unstable magic: if you're counting on stringification
it'll take a crapper.
For instance, as of 2.28 XML::Parser started returning a ref for it's
content model, but uses stringification for backwards compatibility.
This would cause all tests that depend on the string contents to fail.
I think either expect/ok should be completely simple or very
sophisticated. In compsci terms, this corresponds to doing either a
very simple "deep equality" check on references (which eq() does by dint
of the stringification of refs containing their memory address) or it
should do a recursive "shallow equality" check on refs, which means that
the two refs must point to exactly parallel data structures with the
same contents. I think the latter may well be foiled by psuedo-hashes,
and it's a lot more work. So your approach of having helper functions
is the better way there, I think, and ok()/expect() should just do an
eq() and not ever call ref(). Users will grok that easier anyway,
especially since ok() prints out the got vs. expected values.
> Or doing something like
> thinking hash keys can hold references.
I think failing tests will catch most of those cases. Certainly Test.pm
has not raised any complaints of this nature that I've seen. But I
think it makes very little functional difference, is what
> > > 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.
It's an English idiom, and therefor less readable to our German and
Brazilian friends, all for the sake of saving a letter. I really think
isn't is cute though, kind of like the D'oh module.
> > Stray thought: test names must match /\D/ or output will be too
> > confusing.
>
> Good thought. Maybe it'll just be a warning.
Agreed.
>
> is() and is_not (or isnt() or isn't(), dunno) sound good.
definitely
> pass() and fail()... yeah I guess so.
I'm not strongly in favor of them, they just came to mind.
> ok_if() is too wordy for something so common. Keep it ok() and see below.
hokey dokey.
> How about is_like() for regexes? or like()?
> like($x, qr/$y/, [$test_name]);
cool.
> (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.
I say don't bother in that case, since it's more code => more bugs and
Test.pm is always there. If you provide enough extra value people will
want to switch, especially if you can detect old-style ok() calls and
give a helpful suggestion like "did you forget to convert from Test::ok
to Testing::ok", as perl does in some other cases.
- Barrie
