On Fri, Apr 02, 2010 at 12:03:13AM -0700, Ovid wrote: > I see no one's answered this yet. I was hoping for more clarification > lest my (mis)understanding hampers things. You have a large data > structure to share across tests and I assume either some code builds it > and others than need it or it's expensive to build? If it's the > former, it implies an ordering dependency and coupling in your tests > which greatly lowers their utility.
It's more the former than the latter, and yes, it does lower the tests' utility. The application suffers from its monolithic architecture. We had previously tried to use mock objects to do all the testing but most of the mock objects ended up needing to be "close enough" to the real thing to defeat the purpose. > If the structure is simply expensive, have you considered running > tests in a single process to ensure the data structure doesn't go away? > Test::Class and Test::Aggregate can both let you do this. Test::Class looks a lot like what I've come up with internally (only much cleaner and more well-thought, and without the dependency tracking that I've written to deal with test dependencies). Maybe I should port my solution to Test::Class and write something similar to Test::Class::Load (maybe called Test::Class::Dependency) to manage the automatic loading of dependent classes (e.g. for test D, load tests A and B automatically and make sure to run them first)? Or do you think I should stick with my custom solution? Thanks, -- Erik
