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?
> > 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;
}
Although this could cause problems with objects that overload
stringification...
Maybe eq() should be a very strict version of expect() and expect() can
do some DWIM stuff.
> This is a special case that I use a *lot*, especially when testing
> exception tossing code.
Hmm, never thought of that.
> > What if instead I wrote it like this:
> >
> > todo {
> > ok( My::Module->new_method );
> > my @args = qw(blurp blurp blurp);
> > ok( My::Module->new_method(@args) );
> > } q{My::Module->can't("new_method") yet},
> > My::Module->can('new_method');
>
> Then it's not really a todo(), I think: it's done, just not in older
> code. Why should a test like this fail against older code? You're
> testing added capabilities, seems like a skip() might be more
> semantically correct here, if Aegis can cope with it. It really seems
> like you should skip tests if the old code can't support it.
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).
Part of the sementics is if we're writing the test before or *after*
we implement the change. Its supposed to be before (so its a todo),
but it often winds up after (where its a skip).
I'm writing a quiet version of Test::Harness::runtests() that returns
raw data on what passed, what failed, what skipped, what's todo and
what unexpectedly passed. Once that's in place, you can determine how
to interpret skips and todos appropriate to special environments (like
Aegis).
So in this case, I'd have Aegis interpret todo tests as failures.
Unexpected successes would also be considered failures.
> > todo { test } $why, $until;
> > skip { test } $why, $until;
>
> Can the until be optional? Your need is more sophisticated than most, I
> think.
Oh, definately optional. Sorry for not making that clear.
> Really wish we could do the omit-the-sub trick on later params. Boy I
> do. Or I wish that filters were more sophisticated, if Damian can write
> switch...
Banish Evil Thoughts.
> > my $this_obj = My::Cached::Class->new($id);
> > my $same_obj = My::Cached::Class->new($id);
> >
> > expect( $this_obj, $same_obj, 'caching is working' );
>
> 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.
> You can do
>
> ok( $a eq $b, 1, "test name" ) ;
>
> in today's Test.pm and I do it all the time. In fact, I'm wondering if
> expect() is really needed at all?
I find that very icky. I don't like unnecessary extra arguments. I
also hate the implication that "($a eq $b) equals 1" which isn't quite
the same as saying "($a eq $b) is true".
It encourages tests like:
ok( $obj->is_foo, 1 );
Which says "I expect $obj->is_foo to return 1" which is not the same
as "I expect $obj->is_foo to return a true value". Ditto 0 and false.
I've deliberately made routines like is_foo() return things like
"basset hounds got long ears" just to screw with tests like that.
The only way I can think of getting around that is:
ok( !!$obj->is_foo, 1 );
Ick.
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()?
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Sometimes these hairstyles are exaggerated beyond the laws of physics
- Unknown narrator speaking about Anime
