is(actual, expected, [test-name])¶

This is the equivalent of Test::More's "is" function with one interesting twist. If your actual and expected results differ and the output is multi-line, this function will show you a unified diff format of output. Consider the benefit when looking for the one character that is different in hundreds of lines of output!

Diff output requires the optional "Text::Diff" CPAN module. If you don't have this module, the "is()" function will simply give you normal Test::More output. To disable diffing altogether, set the "TEST_SHOW_NO_DIFFS" environment variable (or $ENV{TEST_SHOW_NO_DIFFS}) to a true value. You can also call the "no_diff" function as a shortcut.

blocks( [data-section-name] )¶

The most important function is "blocks". In list context it returns a list of "Test::Base::Block" objects that are generated from the test specification in the "DATA" section of your test file. In scalar context it returns the number of objects. This is useful to calculate your Test::More plan.

Each Test::Base::Block object has methods that correspond to the names of that object's data sections. There is also a "name" and a "description" method for accessing those parts of the block if they were specified.

The "blocks" function can take an optional single argument, that indicates to only return the blocks that contain a particular named data section. Otherwise "blocks" returns all blocks.

    my @all_of_my_blocks = blocks;
    my @just_the_foo_blocks = blocks('foo');

next_block()¶

You can use the next_block function to iterate over all the blocks.

    while (my $block = next_block) {
        ...
    }

It returns undef after all blocks have been iterated over. It can then be called again to reiterate.

first_block()¶

Returns the first block or undef if there are none. It resets the iterator to the "next_block" function.

run(&subroutine)¶

There are many ways to write your tests. You can reference each block individually or you can loop over all the blocks and perform a common operation. The "run" function does the looping for you, so all you need to do is pass it a code block to execute for each block.

The "run" function takes a subroutine as an argument, and calls the sub one time for each block in the specification. It passes the current block object to the subroutine.

    run {
        my $block = shift;
        is(process($block->foo), $block->bar, $block->name);
    };

run_is([data_name1, data_name2])¶

Many times you simply want to see if two data sections are equivalent in every block, probably after having been run through one or more filters. With the "run_is" function, you can just pass the names of any two data sections that exist in every block, and it will loop over every block comparing the two sections.

    run_is 'foo', 'bar';

If no data sections are given "run_is" will try to detect them automatically.

NOTE: Test::Base will silently ignore any blocks that don't contain both sections.

is_deep($data1, $data2, $test_name)¶

Like Test::More's "is_deeply" but uses the more correct Test::Deep module.

run_is_deeply([data_name1, data_name2])¶

Like "run_is_deeply" but uses "is_deep" which uses the more correct Test::Deep.

run_is_deeply([data_name1, data_name2])¶

Like "run_is" but uses "is_deeply" for complex data structure comparison.

run_is_deeply([data_name1, data_name2])¶

Like "run_is_deeply" but uses "is_deep" which uses the more correct Test::Deep.

run_like([data_name, regexp | data_name]);¶

The "run_like" function is similar to "run_is" except the second argument is a regular expression. The regexp can either be a "qr{}" object or a data section that has been filtered into a regular expression.

    run_like 'foo', qr{<html.*};
    run_like 'foo', 'match';

run_unlike([data_name, regexp | data_name]);¶

The "run_unlike" function is similar to "run_like", except the opposite.

    run_unlike 'foo', qr{<html.*};
    run_unlike 'foo', 'no_match';

run_compare(data_name1, data_name2)¶

The "run_compare" function is like the "run_is", "run_is_deeply" and the "run_like" functions all rolled into one. It loops over each relevant block and determines what type of comparison to do.

NOTE: If you do not specify either a plan, or run any tests, the "run_compare" function will automatically be run.

delimiters($block_delimiter, $data_delimiter)¶

Override the default delimiters of "===" and "---".

spec_file($file_name)¶

By default, Test::Base reads its input from the DATA section. This function tells it to get the spec from a file instead.

spec_string($test_data)¶

By default, Test::Base reads its input from the DATA section. This function tells it to get the spec from a string that has been prepared somehow.

filters( @filters_list or $filters_hashref )¶

Specify a list of additional filters to be applied to all blocks. See FILTERS below.

You can also specify a hash ref that maps data section names to an array ref of filters for that data type.

    filters {
        xxx => [qw(chomp lines)],
        yyy => ['yaml'],
        zzz => 'eval',
    };

If a filters list has only one element, the array ref is optional.

filters_delay( [1 | 0] );¶

By default Test::Base::Block objects are have all their filters run ahead of time. There are testing situations in which it is advantageous to delay the filtering. Calling this function with no arguments or a true value, causes the filtering to be delayed.

    use Test::Base;
    filters_delay;
    plan tests => 1 * blocks;
    for my $block (blocks) {
        ...
        $block->run_filters;
        ok($block->is_filtered);
        ...
    }

In the code above, the filters are called manually, using the "run_filters" method of Test::Base::Block. In functions like "run_is", where the tests are run automatically, filtering is delayed until right before the test.

filter_arguments()¶

Return the arguments after the equals sign on a filter.

    sub my_filter {
        my $args = filter_arguments;
        # is($args, 'whazzup');
        ...
    }
    __DATA__
    === A test
    --- data my_filter=whazzup

tie_output()¶

You can capture STDOUT and STDERR for operations with this function:

    my $out = '';
    tie_output(*STDOUT, $buffer);
    print "Hey!\n";
    print "Che!\n";
    untie *STDOUT;
    is($out, "Hey!\nChe!\n");

no_diff()¶

Turn off diff support for is() in a test file.

default_object()¶

Returns the default Test::Base object. This is useful if you feel the need to do an OO operation in otherwise functional test code. See OO below.

WWW() XXX() YYY() ZZZ()¶

These debugging functions are exported from the Spiffy.pm module. See Spiffy for more info.

croak() carp() cluck() confess()¶

You can use the functions from the Carp module without needing to import them. Test::Base does it for you by default.

Scalar vs List¶

Each filter can take either a scalar or a list as input, and will return either a scalar or a list. Since filters are chained together, it is important to learn which filters expect which kind of input and return which kind of output.

For example, consider the following filter list:

    norm trim lines chomp array dumper eval

The data always starts out as a single scalar string. "norm" takes a scalar and returns a scalar. "trim" takes a list and returns a list, but a scalar is a valid list. "lines" takes a scalar and returns a list. "chomp" takes a list and returns a list. "array" takes a list and returns a scalar (an anonymous array reference containing the list elements). "dumper" takes a list and returns a scalar. "eval" takes a scalar and creates a list.

A list of exactly one element works fine as input to a filter requiring a scalar, but any other list will cause an exception. A scalar in list context is considered a list of one element.

Data accessor methods for blocks will return a list of values when used in list context, and the first element of the list in scalar context. This is usually "the right thing", but be aware.

The Stock Filters¶

Test::Base comes with large set of stock filters. They are in the "Test::Base::Filter" module. See Test::Base::Filter for a listing and description of these filters.

Rolling Your Own Filters¶

Creating filter extensions is very simple. You can either write a function in the "main" namespace, or a method in the "Test::Base::Filter" namespace or a subclass of it. In either case the text and any extra arguments are passed in and you return whatever you want the new value to be.

Here is a self explanatory example:

    use Test::Base;
    filters 'foo', 'bar=xyz';
    sub foo {
        transform(shift);
    }
        
    sub Test::Base::Filter::bar {
        my $self = shift;       # The Test::Base::Filter object
        my $data = shift;
        my $args = $self->current_arguments;
        my $current_block_object = $self->block;
        # transform $data in a barish manner
        return $data;
    }

If you use the method interface for a filter, you can access the block internals by calling the "block" method on the filter object.

Normally you'll probably just use the functional interface, although all the builtin filters are methods.

Note that filters defined in the "main" namespace can look like:

  sub filter9 {
      s/foo/bar/;
  }

since Test::Base automatically munges the input string into $_ variable and checks the return value of the function to see if it looks like a number. If you must define a filter that returns just a single number, do it in a different namespace as a method. These filters don't allow the simplistic $_ munging.

name()¶

This is the optional short description of a block, that is specified on the block separator line.

description()¶

This is an optional long description of the block. It is the text taken from between the block separator and the first data section.

seq_num()¶

Returns a sequence number for this block. Sequence numbers begin with 1.

blocks_object()¶

Returns the Test::Base object that owns this block.

run_filters()¶

Run the filters on the data sections of the blocks. You don't need to use this method unless you also used the "filters_delay" function.

is_filtered()¶

Returns true if filters have already been run for this block.

original_values()¶

Returns a hash of the original, unfiltered values of each data section.