NAME

Test::Perl::Critic - Use Perl::Critic in test scripts

SYNOPSIS

  use Test::Perl::Critic;

  critic_ok($file);                          #Test one file
  all_critic_ok($dir_1, $dir_2, $dir_N );    #Test all files in several $dirs
  all_critic_ok()                            #Test all files in distro

DESCRIPTION

Test::Perl::Critic wraps the Perl::Critic engine in a convenient subroutine suitable for test scripts written for Test::Harness. This makes it easy to integrate coding-standards enforcement into the build process. For ultimate convenience (at the expense of some flexibility), see the criticism pragma.

SUBROUTINES

critic_ok( FILE [, TESTNAME ] )

Okays the test if Perl::Critic does not find any violations in FILE. If it does, the violations will be reported in the test diagnostics. The optional second argument is the name of test, which defaults to "Perl::Critic test for FILE".

all_critic_ok( [@DIRECTORIES] )

Runs critic_ok() for all Perl files beneath the given list of directories. If given an empty list, the function tries to find all Perl files in the blib/ directory. If the blib/ directory does not exist, then it tries the lib/ directory.

If you are testing a module, just make a t/criticize.t file with this:

  use Test::More;
  eval 'use Test::Perl::Critic';
  plan skip_all => 'Test::Perl::Critic required to criticise code' if $@;
  all_critic_ok();

Returns true if all files are ok, or false if any file fails.

all_code_files ( [@DIRECTORIES] )

Returns a list of all the Perl files found beneath each DIRECTORY, If @DIRECTORIES is an empty list, defaults to blib/. If blib/ does not exist, it tries lib/. Skips any files in CVS or .svn directories.

A Perl file is:

• Any file that ends in .PL, .pl, .pm, or .t

• Any file that has a first line with a shebang containing 'perl'

CONFIGURATION

Perl::Critic is highly configurable. By default, Test::Perl::Critic 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 Test::Perl::Critic to do the same.

Test::Perl::Critic allows you to configure Perl::Critic by passing the path to a perlcriticrc file in the use pragma. For example:

  use Test::Perl::Critic (-profile => 't/perlcriticrc');
  all_critic_ok();

Now place a copy of your own .perlcritic file in the distribution as t/perlcriticrc. Then, critc_ok() will be run on all Perl files in this distribution using this same Perl::Critic configuration. See the Perl::Critic documentation for details on the .perlcriticrc file format.

DIAGNOSTIC DETAILS

By default, Test::Perl::Critic displays basic information about each Policy violation in the diagnostic output of the test. You can customize the format and content of this information by giving the -format option to the use pragma. For example:

  use Test::Perl::Critic (-format => "%m at line %l, column %c.");
  all_critic_ok();

Formats are a combination of literal and escape characters similar to the way sprintf works. See String::Format for a full explanation of the formatting capabilities. Valid escape characters are:

  Escape    Meaning
  -------   ------------------------------------------------------------------
  %m        Brief description of the violation
  %f        Name of the file where the violation occurred.
  %l        Line number where the violation occurred
  %c        Column number where the violation occurred
  %e        Explanation of violation or page numbers in PBP
  %d        Full diagnostic discussion of the violation
  %r        The string of source code that caused the violation
  %p        Name of the Policy module that created the violation
  %s        The severity level of the violation

CAVEATS

Despite the obvious convenience of using test scripts to verify that your code complies with coding standards, its not really sesible to distribute your module with those scripts. You don't know which version of Perl::Critic the user has and whether they have installed additional Policy modules, you can't really be sure that your code will pass the Test::Perl::Critic tests on another machine.

The easy solution is to add your criticize.t test script to the MANIFEST.SKIP. When you test your build, you'll still be able to run the Perl::Critic tests when you 'make test', but they won't be included in the tarball when you 'make dist'.

See http://www.chrisdolan.net/talk/index.php/2005/11/14/private-regression-tests/ for an interesting discussion about Test::Perl::Critic and other types of author-only regression tests.

EXPORTS

  critic_ok()
  all_critic_ok()

BUGS

Please report all bugs to http://rt.cpan.org. Thanks.

SEE ALSO

Perl::Critic

Test::More

CREDITS

Andy Lester, whose Test::Pod module provided most of the code and documentation for Test::Critic. Thanks, Andy.

AUTHOR

Jeffrey Ryan Thalhammer <thaljef@cpan.org>

COPYRIGHT

Copyright (c) 2005 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.

cpanm Test::Perl::Critic

perl -MCPAN -e shell
install Test::Perl::Critic