I've developed some extensions to Test::Unit that I'd like some input on from others who are more knowledgeable about unit testing concepts. The extensions work perfectly, as far as I can tell. My question is whether these changes are 'correct' within the realm of unit testing or if they are taking the code out of the realm of what is considered (good) unit test design.

The extension is a subclass of Test::Unit::TestCase (I'm callng it Test::Unit::TestCaseVarying^*) that extends the functionality of set_up and tear_down so that each test within a TestCaseVarying can have it's own set of set_up and tear_down routines. This is done by associating with each test method an array with the names of the functions to call (two lists, actually, one for setup and one for teardown). The Test::Unit::TestCaseVarying set_up and tear_down methods then retrieve the appropriate list for the test object that calls them then loops over the list, calling each of these in turn. Here is a slightly simplified version of Test::Unit::TestCaseVarying:

sub set_up
   {
   my $test = shift;
   foreach my $setup ( $test->get_set_up_list() )
      { $test->$setup() }
   }
[download]

The rationale for doing this is that I felt it would be easier to maintain the Unit tests if they parallelled the class hierarchy of the code being tested. This means one TestCase per class with lots of specific test for each method in the class. However, the limitation that all tests within a TestCase all call the same set_up and tear_down routine was problematic because very few tests would share the same needs in terms of available fixture.

So is this a good way to go or is all my cleverness just missing the whole point of unit testing?

^* I'm calling it that for the purposes of this discussion. It's real name is project-specific and not very helpful to the discussion.