[Perlunit-users] Test::Unit in OO environment
Status: Beta
Brought to you by:
mca1001
From: Conrad H. <co...@ne...> - 2004-12-14 16:57:24
|
Hi there, I'm hoping to use Test::Unit in a project I'm about to start writing, but would like suggestions (or maybe pointers to examples) on using it in an OO environment. The POD gives a very basic introduction to Test::Unit::TestCase and how it allows you to inherit tests, but it's not clear to me how to use this feature. Case in point: ChildClass inherits from an abstract ParentClass. All descendants of ParentClass should implement commonMethod, which (for example) should fail cleanly on certain inputs. It seems to me that the test of commonMethod's failure semantics could be usefully implemented in the tests for ParentClass, so all ChildClasses can benefit from that test. *But* I'm not sure how to do this cleanly in Test::Unit. At the moment I was *thinking* of structuring stuff like this: Parent.pm Child.pm isa Parent Test::Parent.pm isa Test::Unit::TestCase Test::Child.pm isa Test::Parent .. but then should I be (in Test::Child::set_up) storing a list of instances of Child objects in some bit of $self that's known about by Test::Parent so Test::Parent can run the commonMethod tests on them? i.e. something like this: { package Test::Child; sub set_up { my $self = shift; $self->{TEST_INSTANCE} = Child->new; } } { package Test::Parent; sub test_commonMethodFailure { my $self = shift; # Try invoking commonMethod badly.. eval { $self->{TEST_INSTANCE}->commonMethod('bad parameter') }; # Look at @_ to see that an error's been generated... } } Does this make sense? Is this storing-child-instances-in-some- contractually-agreed-location-for-the-parent-to-test thing the best way of taking advantage of inheritance in Test::Unit, or is there a better way? Having written the question down, I can see that there's nothing inherently Perl-y about this, so maybe other OO unit testing frameworks have already answered this question - anybody suggest a reference please? Thanks for your time.. Conrad |