On Wednesday 19 July 2006 18:10, Fergal Daly wrote:
> On 20/07/06, chromatic <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 20, 2006 at 12:39:11AM +0100, Fergal Daly wrote:
> > > Simple question. Given this code:
> > >
> > > sub foo {
> > > my $thing;
> > > is($thing->x(), "x"); # line 4
> > > is($thing->y(), "y");
> > > }
> > >
> > > $t1 = Thing->new(1);
> > > foo($t1); # line 9
> > > $t2 = Thing->new(2);
> > > foo($t2);
> I'm talking about line numbers so adding a name is not relevant.
>
> Whether I add $T::B::L or not, I don't get any useful output. If you
> disagree please show me your fixed version.
sub foo :TestHelper
{
# this was just a typo; it's not part of my fix
my $thing = shift;
is($thing->x(), "x", 'checking x attribute');
is($thing->y(), "y", 'checking y attribute');
}
This problem has two parts. You want two pieces of information to debug a
failing test within foo(). The first is "Which object had the failure". The
second is "Which test within the function failed?"
There already exist two long-accepted, well-understood, coded, tested, and
debugged ways to answer both questions. I don't see the value in adding a
third, especially when it's not substantially better than either and can be
wrong in other circumstances!
> > That boiler plate code tells Test::Builder *where* to report the call of
> > the test.
> What's your point?
Your patch relies on $Level too, as it calls the caller() *method* within
Test::Builder. If someone has not set it correctly, your patch will report
the wrong information.
> There's no guessing involved, the method is extremely straight forward
> and always gets the right answer. By that I mean that it always finds
> the spot where test script jumped into the test library.
sub an_extra_level
{
ok( $_[0], $_[1], $_[2] );
}
sub another_extra_level
{
an_extra_level( @_ );
}
sub yet_another_extra_level
{
another_extra_level( @_ );
}
sub still_more_extra_levels
{
yet_another_extra_level( @_ );
}
still_more_extra_levels( $have, $want, $diagnostic );
Where do you start debugging that?
What good does a stack trace do in a loop?
> The problem is that a single position in the test script is not always
> enough information to figure out what actually failed,
That's why there are test descriptions too.
-- c
