Matthew Astley ([EMAIL PROTECTED]) wrote:
> [repost from 9th April]
>
> On Mon, Mar 05, 2001 at 05:24:06PM +0000, Adam Spiers wrote:
> > This patch adds a new runner (state) class. At the moment, the only
> > state you can store is a list of filtering tokens, and whether to
> > quell the backtrace. The latter could well change once we implement a
> > better debugging system, or if we ditch the backtrace altogether.
> >
> > The only significant changes required were:
> >
> > - The runner now gets passed into $suite->run(), and propogated
> > downwards and into the result object.
> >
> > - The three runners (TestRunner, Tk, HarnessUnit) are now derived
> > from T::U::Runner, which ISA T::U::TestListener, rather than each
> > runner being a TestListener. I think this is a bit nicer than
> > multiple inheritance.
> >
> > What do people think?
>
> Sorry for the delay on this. I still haven't actually applied the
> thing and run it, so my comments may not be so relevant.
>
> We have (since?) said we were going to bin the backtrace completely,
> since nobody likes it, so presumably those parts of the patch can go
> too?
Yep, they'll go when the backtrace does.
> In the interest of not causing more confusion when/if we make the
> suite building function take a regexp for the function name, perhaps
> you could take out
>
> $method =~ s/^test_//;
>
> from T:U::Test::filter_method() ? It'll "only" break all your existing
> filters and make them more verbose.
OK. It was only there to save typing when writing the filter() method
in each suite.
> I think the most confusing thing about the filter was the fact that
> it's negative (which makes sense, for removing the slow ones or
> whatever). I can't think of a name for filter_method() or any other
> part that would make this more obvious, though.
I guess it all depends on whether you regard a filter as something
which lets certain stuff through or gets rid of stuff you don't want
:-) I don't think it's too unintuitive when you see it being used though.
> On the whole, though, I say bung the patch in so we can hack on it.
Cool, will do as soon as I've got this pesky deadline out of the way
:-)
Any thoughts on my proposed redesign of TestSuites? In case you
missed it, it was posted on March 7th, subject "TestSuite inheritance
and runner state", although for the lazy amongst you I proposed that
we ditch this
package My::TestSuites::Foo;
sub suite {
my $class = shift;
my $suite = Test::Unit::TestSuite->empty_new('name of suite');
use My::TestSuites::Bar;
$suite->add_test(My::TestSuites::Bar->suite());
use My::TestSuites::Baz;
$suite->add_test(My::TestSuites::Baz->suite());
return $suite;
}
in favour of
package My::TestSuites::Foo;
use base qw(Test::Unit::TestSuite);
sub name { 'name of suite' }
sub subsuites { qw(My::TestSuites::Bar My::TestSuites::Baz) }
which is a hell of a lot easier to read, write, and implement the
framework for. It also means that My::TestSuites::Bar really ISA
TestSuite. It never used to be, which seems rather ridiculous.
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
