On Wed, Mar 14, 2001 at 02:57:42AM +0000, Michael G Schwern wrote:
> On Fri, Mar 09, 2001 at 09:56:37AM -0500, barries wrote:
> > You may want to settle on using underscores everywhere or nowhere in the
> > interests of consistency.
>
> Yeah. Underscores read better but type slower. Hmmm...
Looking up inconsistent ids is slowest :-). I don't find the extra char
'_' causes noticable impact. I optimize for maintainability and put in
'_'. YMMV a lot, though.
> > Perhaps it would be a tad easier to assume noplan if there's no plan
> > call present. Then Test::Harness would complain about not seeing
> > output.
>
> It would be easier, but it would be alot easier to accidentally forget
> to declare a plan up front. No, you have to declare some sort of
> plan, even if its that you have no plan.
>
> Something to make it easier though would be this syntax:
>
> use Testing no_plan;
cool.
> > Perhaps this would work if noplan emitted a line at the end like
> > "Test exiting after $Num_tests\n" or something and Test::Harness
> > whined if that line were not present.
>
> 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".
> > > # Various ways to say "ok"
> > > ok($this eq $that, $test_name);
> > >
> > > expect($this, $that, $test_name);
> > > expect($this, qr/that/, $test_name);
> >
> > Thank you for preserving qr/foo/ and not '/foo/'.
>
> I'm loathe to even keep qr// as a special case. Maybe
>
> 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 ) ;
> It'll
> also make writing the code simpler. Less special input cases to deal
> with.
This is a special case that I use a *lot*, especially when testing
exception tossing code.
> Ooooh, I kind of like that last one!
>
> I'm working with the Aegis CASE system. One of the things you can do is
> require that a new test fails against the baseline code (ie. works with
> your patch, fails without it). Good in practice, but your test has to
> fail, but not puke. So I find myself writing alot of this:
>
> if( My::Module->can('new_method') ) {
> ok( My::Module->new_method );
> my @args = qw(blurp blurp blurp);
> ok( My::Module->new_method(@args) );
> }
> else {
> ok( 0, "My::Module->can('new_method')" );
> }
>
> 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. Also seems
like you should be using a rev number to trigger instead of can(),
otherwise your method could evaporate in a future change and the tests
would still "pass". But I'm reading too much into it, probably.
> If the third argument is true, ok() see that its inside
> Testing::todo() (either through caller or with local variables) and
> print out the magic "# TODO $Skip_Why" comment! Otherwise it runs
> normally. The third argument would be optional. Its basically an
> until statement. "This is a todo test until My::Module::new_method()
> is defined."
>
> skip() could work similarly.
>
> todo { test } $why, $until;
> skip { test } $why, $until;
Can the until be optional? Your need is more sophisticated than most, I
think.
> skip {
> ok( fork );
> ok( flock );
> } q{There is no fork},
> $^O =~ /^MacOS/;
Ooooh, I like!
> We might have to work on the cannonical formatting (it looks a bit
> cluttered at the end), but I think we're onto something here.
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...
> > It'd be happy to see these done
> > quietly by expect(), to keep the API simple. So if expect sees two refs
> > of the same type passed in, it would deep-compare them, for some def of
> > deep. I think
> >
> > expect( \%this, \%that, $test_name ) ;
> >
> > works ($test_name to be optional for me) well in a DWIMMERLY fashion.
>
> No, that's magic. Magic bad. Tests should be fairly strict.
> Consider testing a cached object constructor to make sure it returns
> the same object referents (or perhaps a singleton class):
>
> 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).
> Fortunately, it wouldn't be hard at all to write a new Testing::DWIM
> module built on top of Testing:
>
> sub Testing::DWIM::expect {
> my($this, $that) = @_;
> if( ref $this eq 'HASH' and ref $that eq 'HASH' ) {
> return eq_hash($this, $that);
> }
> elsif( ref $this eq 'ARRAY' and ref $that eq 'ARRAY' ) {
> return eq_array($this, $that);
> }
> else {
> return Testing::expect($this,$that);
> }
> }
>
>
> > > not ok 5 - simple exponential
> >
> > Please don't forget to print the caller's file and line here.
>
> Repeating the same file over and over again will rapidly get annoying, but
> the line number will be useful yes.
Only print it on failure, I mean. Shouldn't be that many failures in
usual cases.
> > Might also be cool to allow the test program to set a "confess" flag
> > that gives you stack dumps for failing tests, I have cases where
> > ok() is buried inside a utility sub and thus it's hard to tell what
> > file and line the croak is on.
>
> Good idea. Would that be on a per-test basis, or overall?
Overall would be fine for me and is simpler to write, document and use,
IMHO.
> Maybe
> something like:
>
> use Testing plan tests => 23, confess => 1;
>
> And a more general
>
> use Testing plan tests => 23, on_not_ok => \&Cry;
>
> Both might be useful.
>
>
> > > ok 6 - force == mass * acceleration
> > >
> > > The later gives you some idea of what failed. It also makes it easier
> > > to find the test in your script, simply search for "simple
> > > exponential".
> >
> > Hmmm, should testing warn if you give the same name to two tests?
>
> Might be worthwhile to make that a plan option. Dunno if it should be
> default.
I take it back: I think with name+file+line_number printed on failing
tests there's no need to warn on this. That way the test name can be
used for a whole bunch of related ok()s without loss of uniqueness.
> > > ok($this eq $that);
> > > ok($this eq $that, $test_name);
> >
> > This is implicitly promoting the call with lower diagnostic value.
>
> You're right. (I habitually put calls in order of least arguments)
>
>
> > Hey, howabout Huffman coding the API so the more useful, presumably more
> > used, call is shortest:
> >
> > ok( $this, $that, $test_name ) ;
> > test_assert( $this eq $that, $test_name ) ;
> >
> > Also continues the tradition of ok()ing things for most tests.
>
> Hmm, looking at the Class::DBI tests about half of them could use
> expect() and half couldn't. Some could be split up into an expect()
> and an ok()... but its still split. Granted that's not exactly a
> statistical samping, but it is a fairly complicated test.
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?
> Maybe we could cut down expect() into something smaller. Ummm,
> test()? ;) A little too generic is the only problem.
Yeah, I considered & rejected it too.
