Adam Spiers <[EMAIL PROTECTED]> 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?
_______________________________________________
Perlunit-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perlunit-devel
