--- Sam Vilain <[EMAIL PROTECTED]> wrote: > Ovid wrote: > > If you have slow test suites, you might want to give it a spin and > see > > if it helps. Essentially, it concatenates tests together and runs > them > > in one process. Thus, you load Perl only once and load all modules > > only once. > > Yuck. > > Why not just load Perl once and fork for the execution of each test > script. You can pre-load modules before you fork.
Forking is also more likely to be used for parallelization. Often code requires sweeping changes before it can be run in parallel. So this means we're reduced to running the code sequentially and forking doesn't offer a huge advantage and can mask hidden state assumptions like when naughty code is munging globals such as filehandles or built-in globals. Also, since forking is only emulated on Windows, it's not reliable (I've had it crash and burn more than once). I prefer to avoid writing modules that are limited to specific platforms. (I'm not saying forking is a bad solution, just a different one). Finally, Test::Aggregate is designed to have tests run with minimal changes. For many tests, just move them to the aggregate directory. No worries about which modules to preload or anything like that. Finally, if you think my code is such a bad idea, I'm sure folks would welcome alternatives. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
