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 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.

            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
        :)

    *   Per-plugin configuration for distros so we can override the default
        config

    *   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.07';/"

    *   Use Test::GreaterVersion to sanity check versions

        The problem here is that I've got to learn the CPAN backend to
        extract the module name from the distro tarball, and pass it on to
        the test...

    *   Use Test::PerlTidy to check code style

        Br0ken install at this time... ( PerlCritic can do that! Need to
        investigate more... )

    *   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::LatestPrereqs

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

    *   Test::PPPort

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

    *   Test::PureASCII

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

    *   Test::Pod::Content

        Maybe this is useful to test my "common" boilerplate POD and make
        sure they are the "latest", eh?

SEE ALSO
    None.

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

        perldoc Test::Apocalypse

  Websites
    *   Search CPAN

        <http://search.cpan.org/dist/Test-Apocalypse>

    *   AnnoCPAN: Annotated CPAN documentation

        <http://annocpan.org/dist/Test-Apocalypse>

    *   CPAN Ratings

        <http://cpanratings.perl.org/d/Test-Apocalypse>

    *   CPAN Forum

        <http://cpanforum.com/dist/Test-Apocalypse>

    *   RT: CPAN's Request Tracker

        <http://rt.cpan.org/NoAuth/Bugs.html?Dist=Test-Apocalypse>

    *   CPANTS Kwalitee

        <http://cpants.perl.org/dist/overview/Test-Apocalypse>

    *   CPAN Testers Results

        <http://cpantesters.org/distro/T/Test-Apocalypse.html>

    *   CPAN Testers Matrix

        <http://matrix.cpantesters.org/?dist=Test-Apocalypse>

  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.

