views:

96

answers:

2

I've written a simple test case based on Test::Perl::Critic which runs critic on every single source file in the repository (all_critic_ok). However, this test takes a long time, especially since I also use a Perl::Tidy policy.

Normally, criticizing different files is not dependent on other critics, so I thought I could parallelize those tests. As it turns out, TAP::Harness can indeed parallelize tests, but only file-wise, not test-wise.

How would you parallelize those tests? Any workaround will do.

+3  A: 

Hack #68 in Perl Hacks has a recipe for running tests persistently using PersistentPerl. You might be able to adapt it for this purpose.

Sinan Ünür
A: 

If you have a large number of files, then creating multiple Test::Perl::Critic test scripts might not be such a bad idea. For example, Perl-Critic itself has three Test::Perl::Critic scripts: one for checking application code, one for test code, and another for the *.run files. And each of these uses a slightly different set of rules.

So if you can divide your code into at least two logical groups and create separate Test::Perl::Critic scripts for them, then you can get at least 2x performance improvement by running them in parallel with Tap::Harness.

Additionally, you can activate the PPI cache (see the Test::Perl::Critic documentation for directions). But that will only make a modest performance improvement.

If you're really interested in making Test::Perl::Critic truly run in parallel, then you're very welcome to contribute code. You can register for a commit bit at http://perlcritic.tigris.org.

Jeffrey Thalhammer