|more useful options|
Re^3: Test::Class and test organizationby xdg (Monsignor)
|on Mar 22, 2006 at 03:15 UTC||Need Help??|
Could you share some examples of the other dimension in your grid? What I think you're saying is that you have a set of input data that you want to use repetitively in different tests -- but I'm not clear on whether these different tests are classes or subsets of functionality of the classes.
I'm not sure this necessarily calls for Test::Class. What about factoring all the test cases into a helper module:
Create all the separate .t files using that package for input data:
In the Test::Class paradigm, I think this would done with a superclass and the individual test classes would inherit from it:
This is similar to how something like CGI::Application recommends using an application-wide superclass to provide the common DBI connection and security but individual subclasses for different parts of the application. I'm not sure exactly how to get the plan right, though.
For another approach (similar to the first one I mentioned), you might want to look at how I structured the tests for Pod::WikiDoc. I put all the test cases as individual files in subdirectories, and then my *.t files called on some fixture code to run a callback function on each test case in a directory. (This is almost exactly what Test::Base is designed to do, but I wanted to avoid that dependency.)
Is any of this helpful for what you're trying to do?
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.