On 30 Jul 2005, at 01:05, Andy Lester wrote:
On Fri, Jul 29, 2005 at 03:57:07PM -0700, Michael G Schwern
([EMAIL PROTECTED]) wrote:
This is, IMHO, the wrong place to do it. The test should not be
responsible
for decorating results, Test::Harness should be. It means you can
decorate
ANY test, not just those that happen to use Test::Builder.
This also coincides with the premise that Test::Harness::Straps are
just
parsing TAP from any given source.
I took chromatic to mean that he'd like the test harness to do the
decorating... so you could do something along the lines of:
----
{ package GrowlingFailure;
use base qw( Test::Harness::Test::Failure );
use Mac::Growl::Testing;
sub action {
my $self = shift
Mac::Growl::Testing->failed(
title => $self->name
description => $self->diagnostics
);
$self->SUPER::action;
}
}
{ package GrowlingTodo;
use base qw( Test::Harness::Test::Todo );
use Mac::Growl::Testing;
sub action {
Mac::Growl::Testing->unexpected_pass(
description => $self->diagnostics
) if $self->actually_passed;
$self->SUPER::action;
}
}
{ package GrowlingTestHarness;
use base qw( Test::Harness );
sub failure_test_class { 'GrowlingFailure' }
sub todo_test_class { 'GrowlingToodo' }
}
# show me pretty dialogs for test failures
GrowlingTestHarness->new->analyse_files( @ARGV );
----
So we have the underlying test harness producing different classes
for each variety of test.
(BTW chromatic: I'm curious why you didn't break todo tests into
separate passing/failing classes as you did the "normal" test?)
Adrian