/ 
Test-Apocalypse-0.10
River stage one • 1 direct dependent • 1 total dependent
/ Test::Apocalypse

NAME

Test::Apocalypse - Apocalypse's favorite tests bundled into a simple interface

SYNOPSIS

#!/usr/bin/perl
use strict; use warnings;

use Test::More;
eval "use Test::Apocalypse";
if ( $@ ) {
	plan skip_all => 'Test::Apocalypse required for validating the distribution';
} else {
	# lousy hack for kwalitee
	require Test::NoWarnings; require Test::Pod; require Test::Pod::Coverage;
	is_apocalypse_here();
}

ABSTRACT

Using this test module simplifies/bundles common distribution tests favored by the CPAN id APOCAL.

DESCRIPTION

This module greatly simplifies common author tests for modules heading towards CPAN. I was sick of copy/pasting the tons of t/foo.t scripts + managing them in every distro. I thought it would be nice to bundle all of it into one module and toss it on CPAN :) That way, every time I update this module all of my dists would be magically updated!

This module respects the RELEASE_TESTING/AUTOMATED_TESTING env variable, if it is not set it will skip the entire testsuite. Normally end-users should not run it; but you can if you want to see how bad my dists are, ha! The scheme is exactly the same as the one Alias proposed in Test::XT and in his blog post, http://use.perl.org/~Alias/journal/38822.

This module uses Module::Pluggable to have custom "backends" that process various tests. We wrap them in a hackish Test::Block block per-plugin and it seems to work nicely. If you want to write your own, it should be a breeze once you look at some of my plugins and see how it works. ( more documentation to come )

Usage

In order to use this, you would need to be familiar with the "standard" steps in order to fully exercise the testsuite. There are a few steps we require, because our plugins need stuff to be prepared for them. For starters, you would need a test file in your distribution similar to the one in SYNOPSIS. Once that is done and added to your MANIFEST and etc, you can do this:

perl Build.PL			# sets up the dist ( duh, hah )
./Build dist			# makes the tarball ( so certain plugins can process it )
RELEASE_TESTING=1 ./Build test	# runs the testsuite!

Methods

is_apocalypse_here()

This is the main entry point for this testsuite. By default, it runs every plugin in the testsuite. You can enable/disable specific plugins if you desire. It accepts a single argument: a hashref or a hash. It can contain various options, but as of now it only supports two options. If you try to use allow and deny at the same time, this module will throw an exception.

allow

Setting "allow" to a string or a precompiled regex will run only the plugins that match the regex. If passed a string, this module will compile it via qr/$str/i.

# run only the EOL test and disable all other tests
is_apocalypse_here( {
	allow	=> qr/^EOL$/,
} );

# run all "dist" tests
is_apocalypse_here( {
	allow	=> 'dist',
} );

deny

Setting "deny" to a string or a precompiled regex will not run the plugins that match the regex. If passed a string, this module will compile it via qr/$str/i.

# disable Pod_Coverage test and enable all other tests
is_apocalypse_here( {
	deny	=> qr/^Pod_Coverage$/,
} );

# disable all pod tests
is_apocalypse_here( {
	deny	=> 'pod',
} );

plugins()

Since this module uses Module::Pluggable you can use this method on the package to find out what plugins are available. Handy if you need to know what plugins to skip, for example.

WARNING: We enable the "require" option to Module::Pluggable so that means the plugins returned are objects.

my @tests = Test::Apocalypse->plugins;

EXPORT

Automatically exports the "is_apocalypse_here" sub.

MORE IDEAS

  • Document the way we do plugins so others can add to this testsuite :)

  • POD standards check

    Do we have SYNOPSIS, ABSTRACT, SUPPORT, etc sections? ( PerlCritic can do that! Need to investigate more... )

  • Help with version updates automatically

    This little snippet helps a lot, I was wondering if I could integrate it into the testsuite hah!

    find -name '*.pm' | grep -v /blib/ | xargs sed -i "s/\$VERSION = '[^']\+\?';/\$VERSION = '0.10';/"

  • Integrate Test::UniqueTestNames into the testsuite

    This would be nice, but I'm not sure if I can actually force this on other tests. Otherwise I'll be just making sure that the Test::Apocalypse tests is unique, which is worthless to $dist trying to clean itself up...

  • META.yml checks

    We should make sure that the META.yml includes the "repository", "license", and other useful keys!

  • Other AUTHORs

    As always, we should keep up on the "latest" in the perl world and look at other authors for what they are doing.

  • indirect syntax

    We should figure out how to use indirect.pm to detect this deprecated method of coding. There's a Perl::Critic plugin for this, yay!

  • Test::PPPort

    Already implemented as PPPort.pm but it's less invasive than my version, ha!

  • Test::DependentModules

    This is a crazy test, but would help tremendously in finding regressions in your code!

  • Test::CleanNamespaces

    I don't exclusively code in Moose, but this could be useful...

  • Test::Vars

    This looks useful to detect unused vars ( copy/paste errors? heh )

Modules that I considered but decided against using

  • Test::MyDeps

    Superseded by Test::DependentModules

  • Test::NoTabs

    I always use tabs! :(

  • Test::CheckManifest

    This was a buggy dist that I dropped and is now using Test::DistManifest

  • Test::Dist

    This is pretty much the same thing as this dist ;)

  • Test::PureASCII

    This rocks, as I don't care about unicode in my perl! ;)

  • Test::LatestPrereqs

    This looks cool but we need to fiddle with config files? My OutdatedPrereqs test already covers it pretty well...

  • Test::Pod::Content

    This is useful, but not everyone has the same POD layout. It would be too much work to try and generalize this...

  • Test::GreaterVersion

    Since I never use CPAN, this is non-functional for me. However, it might be useful for someone?

  • Test::Kwalitee

    This dist rocks, but it doesn't print the info nor utilize the extra metrics. My homebrew solution actually copied a lot of code from this, so I have to give it props!

  • Test::LoadAllModules

    This is very similar to Test::UseAllModules but looks more complicated. Also, I already have enough tests that do that ;)

  • Test::ModuleReady

    This looks like a nice module, but what it does is already covered by the numerous tests in this dist...

  • Test::PerlTidy

    Br0ken install at this time... ( PerlCritic can do that! Need to investigate more... ) Also, all it does is... run your module through perltidy and compare the outputs. Not that useful imo because I never could get perltidy to match my prefs :(

  • Test::Install::METArequires

    This looks like a lazy way to do auto_install and potentially dangerous! Better to just use the prereq logic in Build.PL/Makefile.PL

  • Test::Perl::Metrics::Simple

    This just tests your Cyclomatic complexity and was the starting point for my homebrew solution.

SEE ALSO

None.

SUPPORT

You can find documentation for this module with the perldoc command.

perldoc Test::Apocalypse

Websites

Bugs

Please report any bugs or feature requests to bug-test-apocalypse at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Apocalypse. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

AUTHOR

Apocalypse <apocal@cpan.org>

Thanks to jawnsy@cpan.org for the prodding and help in getting this package ready to be bundled into debian!

COPYRIGHT AND LICENSE

Copyright 2010 by Apocalypse

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

The full text of the license can be found in the LICENSE file included with this module.