Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
test-more-users
Home
About this group
Contact owner to join
Message from discussion Test::Builder calling convention
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Michael G Schwern  
View profile  
 More options Mar 13 2009, 10:09 pm
From: Michael G Schwern <schw...@pobox.com>
Date: Fri, 13 Mar 2009 19:09:08 -0700
Local: Fri, Mar 13 2009 10:09 pm
Subject: Re: [test-more-users] Re: Test::Builder calling convention
Print | View thread | Show original | Report this message | Find messages by this author

Aristotle Pagaltzis wrote:
> * Michael G Schwern <schw...@pobox.com> [2009-03-13 19:55]:
>> I don't like the complexity and magic of determining when the
>> result should output and would like to see and good ideas on
>> that.

> Hmm, `undef $ok` sounds like a perfectly good explicit interface
> way to flush the test to me.

That's even worse than $ok->flush.  It's like having a toilet that you have to
take the lid off the tank and pull the stopper manually [1] and the plumber's
fix is to put up a sign that says "to flush open tank, pull stopper".

The whole problem is that they have to think about this at all.  That its an
extra, unexpected step.  Doesn't matter so much what that extra step is.  That
calling $builder->ok() is not enough and you might run into odd cases where
tests will come out of order.

{
    my $ok = $builder->ok($test);
    unless( $ok ) {
        my $diag = ...;
        $ok->diag($diag);
    }

    $builder->ok( $another_test )
            ->name( $name );

}

If object destruction causes output, the second test will be output before the
first.  To avoid this, the test author has to add an $ok->flush (or undef $ok
or whatever) once they're done with the object.  No matter how much we
document it, this is a bug generator.

It also means if a user innocently stores $ok they might not get output until
the process exits.

> And variable scope is a nice
> implicit interface. If you want a less manual interface, you can
> always add a method or two to do this:

>       $builder
>         ->ok($test)
>         ->name($name)
>         ->if_not_ok( sub {
>           my $diag = ...;
>           # ...build up $diag...
>           $_->diag($diag);
>         } );

Reimplementing Perl's control structures is a road I do not want to walk down.

[1] I realize I may have lost the Europeans with this analogy.

--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after eating a junior mint.
    -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
           by Tami Farmer


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google