On 22 Jul 2006, at 15:30, Fergal Daly wrote:
[snip]
There are two reasons to use subroutines.
1 to group related code in a single unit with a descriptive name
2 code reuse - calling the subroutine from multiple places
Your example is #1 and T::B currently supports it perfectly. It does
not support #2 and I have written far more tests involving #2 than #1.
[snip]
I think it would be more accurate to say that T::B only supports #2
if those subroutines are abstracted as test assertions, with
Test::Builder::Level set appropriately. For example Test::Exception's
throws_ok is doing both #1 and #2.
Obviously this is more work for the person writing the subroutines.
Sometimes a lot of work if a lot of the information about the test
fixture is captured in the call stack.
[snip]
This is a different point, Test::Class inverts the usual flow of
control. I agree that a plain old stack trace in that situation would
be troublesome. I also agree that a solution could be found but it
might not be so pleasant. That's fine by me if Test::Class users don't
want stack traces they don't have to have them,
[snip]
Optional stack traces sound like a nice idea to me. Also pretty
trivial to implement.
<pause class="typing>...</pause>
----
package Test::Builder::StackTrace;
use Test::Builder;
my $builder = Test::Builder->new;
my $original_ok = \&Test::Builder::ok;
no warnings 'redefine';
*Test::Builder::ok = sub {
my ( $self, $test, $name ) = @_;
local $Test::Builder::Level = $Test::Builder::Level + 1;
$original_ok->( $self, $test, $name );
my ($pack, $file, $line) = $builder->caller;
my $height=0;
{ package DB;
while ( my ( $pack, $file, $line, $sub ) = $builder->caller
( $height++ ) ) {
my $args = join( ', ', @DB::Args );
$builder->diag( " $sub($args) called at $file line
$line" );
}
}
};
1;
----
TIMTOWTDI and all that...
Cheers,
Adrian
