Adam Spiers <[EMAIL PROTECTED]> writes:
> Piers Cawley ([EMAIL PROTECTED]) wrote:
> > So, I'm messing around with stuff and I got bored of writing out all
> > that guff in the various foo.t type tests and came up with something
> > that'll let me do:
> >
> > foo.t
> >
> > use Test::Unit::TestMaker qw/Some::Test::Class/;
> >
> > run_tests;
> >
> > Which is somewhat pleasant.
>
> Why not
>
> use Some::Test::Class;
>
> Some::Test::Class->run();
>
> ?
Where's the listener?
>
> Is Some::Test::Class supposed to be a TestSuite or a TestCase?
> If it's a TestCase, you can already do that. Well almost. Firstly,
> it doesn't work because of a missing use in TestCase (which I just
> fixed), and secondly, the result object doesn't have any listeners.
> Hmm:-)
Well, it's set up to add a default runner as well. The idea being that
we just have a simple tool for writing foo.t files.
> If it's a TestSuite, you can't, and this is because when you write a
> TestSuite, it doesn't inherit from T::U::TestSuite. This seems rather
> nonsensical to me, and has already proved to be a PITA with some
> extensions I've been hacking on. For the curious, this was because I
> wanted to know the classname of the suite, but because it was blessed
> into T::U::TestSuite and then built via the suite() method, I had to
> add an extra _Class key to the object when it was constructed. If
> inheritance had taken its natural course, I could have just looked at
> ref($suite).
>
> So, I propose 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());
>
> 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) }
>
> which is a hell of a lot easier to read, write, and implement the
> framework for. Have I missed reasons against?
I need to think about that (and take a look at what
Test::Unit::TestSuite (why not Test::Unit::Suite BTW?) is trying to
do.)
> > Of course, it'd be nice if I could do:
> >
> > use Test::Unit::TestMaker
> > 'Some::Test::Class' => {filter => qr/^test_},
> > 'Some::Other::Test::Class' => {filter => qr/^test[A-Z]/,
> > todo => [qw(testNonExistentFeature)]},
> > ;
> >
> > run_tests;
>
> Now you're getting very close to stuff I've already done. Did you
> take a look at my runner state patch? Noone seems to have commented
> on it yet :-(
Sorry, not yet. Will do though.
>
> > But that might be running before I can walk. (The 'todo' thing could
> > be a tad tricky to implement. Requires holding state somewhere,
> > probably in the runner.)
>
> Where have I heard that before ...
There's definitely a theme there...
> > Test::Harness also allows you to 'skip' certain tests depending on
> > features of the environment you're testing in (or possibly on
> > whether some other test succeeded or not, but doing test
> > dependencies with unordered tests seems, er, courageous)
>
> ... and that :-)
>
> If you missed my patch, drop me a line and I'll send you another copy.
I'm sure I have it archived somewhere, but another copy wouldn't go
amiss.
--
Piers
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/perlunit-devel
