Re: [Perlunit-devel] runner state

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> OK, I've committed my runner state patch.  It adds a new Runner base
> class which is an appropriate place for runner state common between
> all runners.
> 
> Also committed is a very basic example of how it can be useful: filter
> tokens.  To try it out, add something like this to one of your test
> cases:
> 
>     sub filter {{
>       'slow'        => [ 'test_a_slow_one', 'test_another_slow_one' ],
>       'really_slow' => [ 'test_wow_really_slow' ],
>     }}
> 
> then you can filter out slow tests via
> 
>     my $runner = new Test::Unit::TestRunner();
>     $runner->filter(qw/slow really_slow/);
>     $runner->start($class);
> 
> You can have more flexibility if you override filter_method() instead
> of filter().  The API is such that a test $method will be skipped if
> there is any token $token active for which
> 
>   $test->filter_method($token, $method)
> 
> returns true.  The default behaviour is implemented in T::U::Test, and
> it simply looks at the data structure returned by filter().
> 
> I don't like the way that filter_method() has to be implemented in
> T::U::Test rather than T::U::TestCase.  This is because individual
> tests within a suite are currently TestSuite objects rather than
> TestCase objects.  Is there a good reason for this?  It feels very
> ugly.

Ah yes, this is the scary introspection stuff that I've been somewhat
worried about in how this hangs together. I need to do some *more*
code reading and maybe a spike, see what the code tells me.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?