On Wed, Feb 21, 2001 at 03:08:01AM +0000, Piers Cawley wrote:
> barries <[EMAIL PROTECTED]> writes:
> > On Tue, Feb 20, 2001 at 10:38:43PM +0000, Piers Cawley wrote:
> > <...neat expansion on do_all_tests() concept snipped...>
> >
> > > Well, it's a thought anyway.
> >
> > Seems pretty cool, but I'm trying to perceive the advantage over a pure
> > sequential/functional. I think I'm asking for an example where this
> > adds significant benefit.
>
> (ie: Just hanging more test methods off my test classes as appropriate
> and letting the wonders of OO dispatch and perl's introspection work
> out what tests need to be run when I do a 'make test')
It's late, perhaps, and many bugs to go before I sleep, but how does
this relate to the do_all_tests() proposal, as opposed to the Test::Unit
library (wow, 20 classes and 30 modules!!!)?
I like what you're talking about here and I'd like to find a way to work
it into SelfTest and Pod::Tests, so we could surround said test methods
with some POD so they don't bloat compile time or memory when the
module's abusing itself.
Something like:
package Delivery ;
use SelfTest( -via_methods ) ; ## Or SelfTest::Methods?
=begin testing
sub test_setup {
}
sub foo_test {
}
sub bar_test {
}
=end testing
might allow foo_test and bar_test to be found (by scanning %Delivery::)
and run. Tests perhaps to be run in alphabetical order preceded by
setup_test and teardown_test?
Not sure of how to handle test suite state vs. object state.
Seems like it'd be to search @ISA for test subs to in order to make sure
subclasses weren't violating superclass invariants, etc.
Might also be nice to have a member like assert_valid() that could do
runtime self-checks, perhaps, and SelfTest could stub it out as sub
assert_valid() {} if need be. Stray thought that, though I've found
self-testing objects at runtime to be worth the slowdown in many cases.
- Barrie
