Test::...ressive(3pm)

πŸ“¦
version 0.03 Β· 4 versions
, in debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking

πŸ’– Test::Perl::Critic::Progressive πŸ’–

okay bestie, so this is a page from the User Contributed Perl Documentation (manual section 3pm), and it's about Test::Perl::Critic::Progressive β€” the module that makes your crusty legacy code get its life together one tiny step at a time. no cap.


✨ NAME ✨

Test::Perl::Critic::Progressive β€” gradually enforce coding standards.

like, gradually. we're not doing a glow-up montage in one commit, we're doing a slow, sustainable, sustainable-girlboss glow-up. πŸ¦‹


🌸 SYNOPSIS 🌸

Wanna test one file, or a bunch of files, or everything in one or more directories? bet:

use Test::Perl::Critic::Progressive qw( progressive_critic_ok );
progressive_critic_ok($file1, $file2, $dir1, $dir2);

Wanna test every Perl file in a whole distribution? say less:

use Test::Perl::Critic::Progressive qw( progressive_critic_ok );
progressive_critic_ok();

And the recommended usage for public CPAN distributions β€” this is the one you copy-paste, iykyk:

use strict;
use warnings;
use Test::More;

eval { require Test::Perl::Critic::Progressive };
plan skip_all => 'T::P::C::Progressive required for this test' if $@;

Test::Perl::Critic::Progressive::progressive_critic_ok();

πŸ‘‘ DESCRIPTION πŸ‘‘

okay so, applying coding standards to a huge pile of legacy code? it's giving daunting. genuinely. a lot of the time legacy code is so wildly non-compliant that it feels downright impossible to ever fix. 😭

but here's the thing bestie β€” if you consistently chip away at the problem, you will eventually succeed! and that's the whole vibe. Test::Perl::Critic::Progressive uses the Perl::Critic engine to stop your code from getting worse, and to gradually steer it towards conforming with your chosen coding standards. slow and steady wins. 🐒✨

the most effective way to use this is as a unit test that runs under a continuous-integration system like CruiseControl or AntHill. every time a developer commits changes to the code, this test will fail and the build will break β€” unless it has the same (or fewer) Perl::Critic violations than the last successful test. so the vibes can only go up. πŸ“ˆ

see the "NOTES" section for more details about how this test works.

πŸ’… SUBROUTINES πŸ’…

all of the following subroutines can be exported upon request. or you can export all of them at once using the ':all' tag. dealer's choice, bestie.

progressive_critic_ok(@FILES [, @DIRECTORIES ])

progressive_critic_ok()

uses Perl::Critic to analyze each of the given @FILES, and/or all Perl files beneath the given list of @DIRECTORIES. if no arguments are given, it analyzes all the Perl files in the blib/ directory. if the blib/ directory does not exist, then it tries the lib/, bin/, script/, and scripts/ directory. the results of the analysis will be stored as .perlcritic-history in the same directory where your test script is located.

the first time you run this test, it will always pass. πŸŽ‰ but on each subsequent run, the test will pass only if the number of violations found is less than or equal to the number of violations found during the last passing test. if it does pass, then the history file will be updated with the new analysis results. once all the violations are removed from the code, this test will always pass β€” unless a new violation is introduced. (don't be the one who introduces a new violation. just don't. πŸ™ˆ)

this subroutine emits its own Test::More plan, so you do not need to specify an expected number of tests yourself. iconic behaviour, honestly. πŸ‘‘

get_history_file()

set_history_file($FILE)

these functions get or set the full path to the history file. this is where Test::Perl::Critic::Progressive will store the results of each passing analysis. if the $FILE does not exist, it will be created anew. the default is "$Bin/.perlcritic-history" where $Bin is the directory that the calling test script is located in.

get_total_step_size()

set_total_step_size($INTEGER)

these functions get or set the minimum acceptable decrease in the total number of violations between each test. the default value is zero, which means that you are not required to remove any violations, but you are also not allowed to add any. if you set the step size to a positive number, the test will require you to remove $INTEGER violations each time the test is run. in this case, the particular type of violation that you eliminate doesn't matter. the larger the step size, the faster you'll have to eliminate violations. πŸ”₯

get_step_size_per_policy()

set_step_size_per_policy(%ARGS)

these functions get or set the minimum acceptable decrease in the number of violations of a specific policy between each test. the %ARGS should be "$POLICY_NAME => $INTEGER" pairs, like this:

my %step_sizes = (
   'ValuesAndExpressions::ProhibitLeadingZeros'  =>  2,
   'Variables::ProhibitConditionalDeclarations'  =>  1,
   'InputOutput::ProhibitTwoArgOpen'             =>  3,
);

set_step_size_per_policy( %step_sizes );
progressive_critic_ok();

the default step size for any given Policy is zero, which means that you are not required to remove any violations, but you are also not allowed to add any. but if you wish to focus on eliminating certain types of violations, then increasing the per-policy step size will force you to decrease the number of violations of that particular Policy, while ignoring other types of violations. the larger the step size, the faster you'll have to eliminate violations. ⏩

get_critic_args()

set_critic_args(%ARGS)

these functions get or set the arguments given to Perl::Critic. by default, Test::Perl::Critic::Progressive invokes Perl::Critic with its default configuration. but if you have developed your code against a custom Perl::Critic configuration, you will want to configure this test to do the same. consistency is the vibe. ✨

any %ARGS given to set_critic_args will be passed directly into the Perl::Critic constructor. so if you have developed your code using a custom .perlcriticrc file, you can direct Test::Perl::Critic::Progressive to use a custom file too.

use Test::Perl::Critic::Progressive ( ':all' );

set_critic_args(-profile => 't/perlcriticrc);
progressive_critic_ok();

now place a copy of your own .perlcriticrc file in the distribution as t/perlcriticrc. now, progressive_critic_ok will use this same Perl::Critic configuration. see the Perl::Critic documentation for details on the .perlcriticrc file format.

any argument that is supported by the Perl::Critic constructor can be passed through this interface. for example, you can also set the minimum severity level, or include & exclude specific policies like this:

use Test::Perl::Critic::Progressive ( ':all' );

set_critic_args( -severity => 2, -exclude => ['MixedCaseVars'] );
progressive_critic_ok();

see the Perl::Critic documentation for complete details on its options and arguments.


πŸŽ€ NOTES πŸŽ€

the test is evaluated in two ways. first, the number of violations for each Policy must be less than or equal to the number of the violations found during the last passing test, minus the step size for that Policy. second, the total number of violations must be less than or equal the total number of violations found during the last passing test, minus the total step size. this prevents you from simply substituting one kind of violation for another. (no sneaky tradesies, bestie.)

you can use the total step size and the per-policy step size at the same time. for example, you can set the total step size to 5, and set the per-policy step size for the "TestingAndDebugging::RequireStrictures" Policy to 3. in which case, you'll have to remove 5 violations between each test, but 3 of them must be violations of "TestingAndDebugging::RequireStrictures".

over time, you'll probably add new Policies to your Perl::Critic setup. when Test::Perl::Critic::Progressive uses a Policy for the first time, any newly discovered violations of that Policy will not be considered in the test. however, they will be considered in subsequent tests. it's like a grace period. we love a soft launch. 🫢

if you are building a CPAN distribution, you'll want to add ^t/.perlcritic-history$ to the MANIFEST.SKIP file. and if you are using a revision control system like CVS or Subversion, you'll probably want to configure it to ignore the t/.perlcritic-history file as well. keep the history file out of the group chat, basically. πŸ’€


😭 BUGS 😭

if you find any bugs, please submit them to <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Test-Perl-Critic-Progressive>. thanks. πŸ™


🌈 SEE ALSO 🌈


πŸ¦‹ AUTHOR πŸ¦‹

Jeffrey Ryan Thalhammer <thaljef@cpan.org>


Copyright (c) 2007-2008 Jeffrey Ryan Thalhammer. All rights reserved.

this program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. the full text of this license can be found in the LICENSE file included with this module.


okay that's the whole page bestie, go forth and progressively de-crime your codebase πŸ’…βœ¨

signing off β€” this was perl v5.34.0, dated 2022-06-28, and you were reading the Test::...ressive(3pm) page. mwah. πŸŽ€

πŸ“¦ where this page comes from