Dist::Zilla::Plugin::Test::Compile::PerFile This module is inspired by its earlier sibling "[Test::Compile]". Test::Compile is awesome, however, in the process of its development, we discovered it might be useful to run compilation tests in parallel. This lead to the realization that implementing said functions are kinda messy. However, a further realization is, that parallelism should not be codified in the test itself, because platform parallelism is rather not very portable, so parallelism should only be enabled when asked for. And this lead to the realization that "prove" and "Test::Harness" ALREADY implement parallelism, and ALREADY provide a safe way for platforms to indicate parallelism is wanted. Which means implementing another layer of parallelism is unwanted and unproductive effort ( which may be also filled with messy parallelism-induced bugs ) So, here is the Test::Compile model based on how development is currently proceeding. prove \ ----- 00_compile.t | \ ----- Compile Module 1 | \ ----- Compile Module 2 | \ ----- 01_basic.t That may be fine for some people, but this approach has several fundamental limits: 1. Sub-Tasks of compile don't get load balanced by the master harness. 2. Parallelism is developer side, not deployment side governed. 3. This approach means "prove -s" will have no impact. 4. This approach means "prove -j" will have no impact. 5. This approach inhibits other features of "prove" such as the "--state=slow" So this variation aims to employ one test file per module, to leverage "prove" power. One initial concern cropped up on the notion of having excessive numbers of "perl" instances, e.g: prove \ ----- 00_compile/01_Module_1.t | \ ----- Compile Module 1 | \ ----- 00_compile/02_Module_2.t | \ ----- Compile Module 2 | \ ----- 01_basic.t If we were to implement it this way, we'd have the fun overhead of having to spawn 2 "perl" instances per module tested, which on "Win32", would roughly double the test time and give nothing in return. However, Most of the reason for having a "perl" process per compile, was to separate the modules from each other to assure they could be loaded independently. So because we already have a basically empty compile-state per test, we can reduce the number of "perl" processes to as many modules as we have. prove \ ----- 00_compile/01_Module_1.t | \ ----- 00_compile/02_Module_2.t | \ ----- 01_basic.t Granted, there is still some bleed here, because doing it like this means you have some modules preloaded prior to compiling the module in question, namely, that "Test::*" will be in scope. However, "testing these modules compile without "Test::" loaded" is not the real purpose of the compile tests, the compile tests are to make sure the modules load. So this is an acceptable caveat for this module, and if you wish to be distinct from "Test::*", then you're encouraged to use the much more proven "[Test::Compile]". Though we may eventually provide an option to spawn additional "perl" processes to more closely mimic "Test::*"'s behaviour, the cost of doing so should not be understated, and as this module exist to attempt to improve efficiency of tests, not to decrease them, that would be an approach counter-productive to this modules purpose. INSTALLATION This is a Perl module distribution. It should be installed with whichever tool you use to manage your installation of Perl, e.g. any of cpanm . cpan . cpanp -i . Consult http://www.cpan.org/modules/INSTALL.html for further instruction. Should you wish to install this module manually, the procedure is perl Makefile.PL make make test make install COPYRIGHT AND LICENSE This software is copyright (c) 2017 by Kent Fredric . This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.