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

Reply via email to