Guillermo Roditi

Today, Ovid blogged about long-running test-suites and how to optimize them.

Yesterday, I was thinking about this same exact thing. I have a project where the compile-time hit of the collective libraries that make up the application is a little on the heavy side. I thought to myself that it would be good use something like Test::Aggregate, but I wondered if that could mean that some of my tests could be affected by a downstream dependency where the state could be changing at the class level. I don’t think it’s very probable, but it could happen and it would be a real pain to debug.

This is where I came up with the idea that maybe it would be best to load all common libraries in an initial process and then run the actual tests in a fork to benefit from COW to maintain a single compilation phase but still keep run-time data separate. While the approach has it’s own issues, mainly that running the tests in parallel could be a bit of a PITA, I think the idea is worth exploring.

Another thing that I’ve been thinking about lately, is structuring some of my tests as Moose classes and making liberal of use of exception handling to prevent tests from out-right dying and making my BUILD method responsible for making sure any data that the tests require is in good order and making DEMOLISH method responsible for cleaning up after this particular test. The idea here is to keep all the logic related to testing something and then restoring the previous state in the same place.

Again, I haven’t really given extensive thought to this, but I suspect that as some projects grow to a sufficient size, the ideas will resurface.