Alex Balhatchet > Test-Kit-2.02 > Test::Kit

Download:
Test-Kit-2.02.tar.gz

Dependencies

Annotate this POD

CPAN RT

Open  0
View/Report Bugs
Module Version: 2.02   Source  

NAME ^

Test::Kit - Build custom test packages with only the features you want

DESCRIPTION ^

Test::Kit allows you to create a single module in your project which gives you access to all of the testing functions you want.

Its primary goal is to reduce boilerplate code that is currently littering the top of all your test files.

It also allows your testing to be more consistent; for example it becomes a trivial change to include Test::FailWarnings in all of your tests, and there is no danger that you forget to include it in a new test.

VERSION ^

Test::Kit 2.0 is a complete rewrite of Test::Kit by a new author.

It serves much the same purpose as the original Test::Kit, but comes with a completely new interface and some serious bugs ironed out.

The 'features' such as '+explain' and '+on_fail' have been removed. If you were using these please contact me via rt.cpan.org.

SYNOPSIS ^

Somewhere in your project...

    package MyProject::Test;

    use Test::Kit;

    # Combine multiple modules' behaviour into one

    include 'Test::More';
    include 'Test::LongString';

    # Exclude or rename exported subs

    include 'Test::Warn' => {
        exclude => [ 'warning_is' ],
        renamed => {
            'warning_like' => 'test_warn_warning_like'
        },
    };

    # Pass parameters through to import() directly

    include 'List::Util' => {
        import => [ 'min', 'max', 'shuffle' ],
    };

And then in your test files...

    use strict;
    use warnings;

    use MyProject::Test tests => 4;

    ok 1, "1 is true";

    like_string(
        `cat /usr/share/dict/words`,
        qr/^ kit $/imsx,
        "kit is a word"
    );

    test_warn_warning_like {
        warn "foo";
    }
    qr/FOO/i,
    "warned foo";

    is max(qw(1 2 3 4 5)), 5, 'maximum is 5';

EXCEPTIONS ^

Unable to find package to import into

This means that Test::Kit was unable to determine which module include() was called from. It probably means you're doing something weird!

If this is happening under any normal circumstances please file a bug report!

Subroutine %s() already supplied to %s by %s

This happens when there is a subroutine name collision. For example if you try to include both Test::Simple and Test::More in your Kit it will complain that ok() has been defined twice.

You should be able to use the exclude or rename options to solve these collisions.

Package %s already has an import() sub

This happens when your module has an import subroutine before the first include() call. This could be because you have defined one, or because your module has inherited an import() subroutine through an ISA relationship.

Test::Kit intends to install its own import method into your module, specifically it is going to install Test::Builder::Module's import() method. Test::Builder::Module is an Exporter, so if you want to define your own subroutines and export those you can push onto @EXPORT after all the calls to include().

ISSUES ^

Non-subroutine Exports

For subroutine exports we are able to know exactly what subroutines are exported by using a given module using a combination of Import::Into and namespace::clean. Unfortunately the same trick does not work for exported SCALARs.

This is because the most common case we're trying to handle is the '$TODO' variable from Test::More, but it's impossible to catch that in the symbol table because every symbol table entry has a scalar no matter what. ie the following two packages are indistinguishable:

    # One
    package foo;
    our $x = undef;
    our @x = qw(a b c);

    # Two
    package foo;
    our @x = qw(a b c);

So, instead, Test::Kit simply assumes that the package is an Exporter and walks its @EXPORT array for things which start with '$', '@' or '%'.

This at least works for the $Test::More::TODO case, which is the most common.

SEE ALSO ^

A couple of other modules try to generalize this problem beyond the scope of testing:

ToolSet - Load your commonly-used modules in a single import

Import::Base - Import a set of modules into the calling module

Test::Kit largely differs from these in that it always makes your module a Test::Builder::Module, so that it can behave like Test::More.

AUTHOR ^

Test::Kit 2.0 was written by Alex Balhatchet, <kaoru at slackwise.net>

Test::Kit 0.101 and before were authored by Curtis "Ovid" Poe, <ovid at cpan.org>

syntax highlighting: