TAP::Parser(3perl)

📦

version 5.44.0 · 14 versions

💖 TAP::Parser — the perl manpage, bestie edition 💖

okay so this is TAP::Parser(3perl), straight out of the Perl Programmers Reference Guide, and it's genuinely iconic. grab a strawberry 🍓 and let's go.

✨ NAME ✨

TAP::Parser — parse TAP output. that's the whole job and it does it beautifully.

🌸 VERSION 🌸

Version 3.52

🦋 SYNOPSIS 🦋

use TAP::Parser;

my $parser = TAP::Parser->new( { source => $source } );

while ( my $result = $parser->next ) {
    print $result->as_string;
}

👑 DESCRIPTION 👑

TAP::Parser is designed to produce a proper parse of TAP output. like, a real one. no vibes-based guessing. if you wanna see how to run tests through this module, go peek at the simple harnesses in examples/. 🫶

there's a whole wiki dedicated to the Test Anything Protocol:

<http://testanything.org>

and it includes the TAP::Parser Cookbook:

<http://testanything.org/testing-with-tap/perl/tap::parser-cookbook.html>

iykyk. ✨

💅 METHODS 💅

🎀 Class Methods 🎀

`new`

my $parser = TAP::Parser->new(\%args);

returns a new TAP::Parser object. slay.

the arguments should be a hashref with one of the following keys:

"source"

CHANGED in 3.18

this is the preferred method of passing input to the constructor. main character energy, obviously. 👑

the source is used to create a TAP::Parser::Source that is passed to the iterator_factory_class, which in turn figures out how to handle the source and creates a <TAP::Parser::Iterator> for it. the iterator is used by the parser to read in the TAP stream.

to configure the IteratorFactory use the sources parameter below.

heads up bestie: source, tap and exec are mutually exclusive. pick one. 🚫

"tap"

CHANGED in 3.18

the value should be the complete TAP output.

the tap is used to create a TAP::Parser::Source that is passed to the iterator_factory_class, which in turn figures out how to handle the source and creates a <TAP::Parser::Iterator> for it. the iterator is used by the parser to read in the TAP stream.

to configure the IteratorFactory use the sources parameter below.

note that source, tap and exec are mutually exclusive.

"exec"

must be passed an array reference.

the exec array ref is used to create a TAP::Parser::Source that is passed to the iterator_factory_class, which in turn figures out how to handle the source and creates a <TAP::Parser::Iterator> for it. the iterator is used by the parser to read in the TAP stream.

by default the TAP::Parser::SourceHandler::Executable class will create a TAP::Parser::Iterator::Process object to handle the source. this passes the array reference strings as command arguments to IPC::Open3::open3:

exec => [ '/usr/bin/ruby', 't/my_test.rb' ]

if any test_args are given they will be appended to the end of the command argument list.

to configure the IteratorFactory use the sources parameter below.

note that source, tap and exec are mutually exclusive.

the following keys are optional. (yes, optional, breathe) 😌

"sources"

NEW to 3.18.

if set, sources must be a hashref containing the names of the TAP::Parser::SourceHandlers to load and/or configure. the values are a hash of configuration that will be accessible to the source handlers via config_for in TAP::Parser::Source.

for example:

sources => {
  Perl => { exec => '/path/to/custom/perl' },
  File => { extensions => [ '.tap', '.txt' ] },
  MyCustom => { some => 'config' },
}

this will cause TAP::Parser to pass custom configuration to two of the built-in source handlers — TAP::Parser::SourceHandler::Perl, TAP::Parser::SourceHandler::File — and attempt to load the MyCustom class. see load_handlers in TAP::Parser::IteratorFactory for more detail.

the sources parameter affects how source, tap and exec parameters are handled.

see TAP::Parser::IteratorFactory, TAP::Parser::SourceHandler and subclasses for more details.

"callback"

if present, each callback corresponding to a given result type will be called with the result as the argument if the run method is used:

my %callbacks = (
    test    => \&test_callback,
    plan    => \&plan_callback,
    comment => \&comment_callback,
    bailout => \&bailout_callback,
    unknown => \&unknown_callback,
);

my $aggregator = TAP::Parser::Aggregator->new;
for my $file ( @test_files ) {
    my $parser = TAP::Parser->new(
        {
            source    => $file,
            callbacks => \%callbacks,
        }
    );
    $parser->run;
    $aggregator->add( $file, $parser );
}

"switches"

if using a Perl file as a source, optional switches may be passed which will be used when invoking the perl executable.

my $parser = TAP::Parser->new( {
    source   => $test_file,
    switches => [ '-Ilib' ],
} );

"test_args"

used in conjunction with the source and exec option to supply a reference to an @ARGV style array of arguments to pass to the test program.

"spool"

if passed a filehandle will write a copy of all parsed TAP to that handle. 📝

"merge"

if false, STDERR is not captured (though it is 'relayed' to keep it somewhat synchronized with STDOUT.)

if true, STDERR and STDOUT are the same filehandle. this may cause breakage if STDERR contains anything resembling TAP format, but does allow exact synchronization.

subtleties of this behavior may be platform-dependent and may change in the future. so like… don't build your whole personality on it. 🙈

"grammar_class"

this option was introduced to let you easily customize which grammar class the parser should use. it defaults to TAP::Parser::Grammar.

🧚 Instance Methods 🧚

`next`

my $parser = TAP::Parser->new( { source => $file } );
while ( my $result = $parser->next ) {
    print $result->as_string, "\n";
}

this method returns the results of the parsing, one result at a time. note that it is destructive. you can't rewind and examine previous results. the past is the past bestie 💀

if callbacks are used, they will be issued before this call returns.

each result returned is a subclass of TAP::Parser::Result. see that module and related classes for more information on how to use them.

`run`

$parser->run;

this method merely runs the parser and parses all of the TAP. that's it. that's the whole thing. 🔥

`make_grammar`

make a new TAP::Parser::Grammar object and return it. passes through any arguments given.

the grammar_class can be customized, as described in new.

`make_result`

make a new TAP::Parser::Result object using the parser's TAP::Parser::ResultFactory, and return it. passes through any arguments given.

the result_factory_class can be customized, as described in new.

`make_iterator_factory`

NEW to 3.18.

make a new TAP::Parser::IteratorFactory object and return it. passes through any arguments given.

iterator_factory_class can be customized, as described in new.

🦋 INDIVIDUAL RESULTS 🦋

okay bestie, so if you've actually read this far in the docs (iconic of you), you've literally seen this:

while ( my $result = $parser->next ) {
    print $result->as_string;
}

every single result you get back is a TAP::Parser::Result subclass, and we call those lil guys result types. 💅

Result types

so basically, you fetch individual results off the TAP stream one at a time. there are six types, with examples of each, and here they are:

Version

TAP version 12

Plan

1..42

Pragma

pragma +strict

Test

ok 3 - We should start with some foobar!

Comment

# Hope we don't use up the foobar.

Bailout

Bail out!  We ran out of foobar!

Unknown

... yo, this ain't TAP! ...

each result you fetch is a result object of a different type, no cap. there are common methods that every result object has, and different types may have methods that are unique to just them. sometimes a type method gets overridden in a subclass, but its use is guaranteed to be identical. slay. ✨

Common type methods

`type`

returns the type of result, like comment or test.

`as_string`

prints a string representation of the token. this might not be the exact output tho. tests will have test numbers added if they weren't already there, TODO and SKIP directives get capitalized, and in general everything gets cleaned up. if you need the original text for the token, go look at the raw method instead, bestie.

`raw`

returns the original line of text which was parsed. the receipts, basically. 🧾

`is_plan`

tells you whether or not this is the test plan line.

`is_test`

tells you whether or not this is a test line.

`is_comment`

tells you whether or not this is a comment. heads up: comments will generally only show up in the TAP stream if STDERR is merged to STDOUT. see the merge option. 👀

`is_bailout`

tells you whether or not this is a bailout line.

`is_yaml`

tells you whether or not the current item is a YAML block.

`is_unknown`

tells you whether or not the current line could be parsed. it's giving chaos. 💀

`is_ok`

if ( $result->is_ok ) { ... }

reports whether or not a given result has passed. anything that is not a test result returns true. this is just a convenient lil shortcut that lets you do this:

 my $parser = TAP::Parser->new( { source => $source } );
 while ( my $result = $parser->next ) {
     # only print failing results
     print $result->as_string unless $result->is_ok;
 }

"plan" methods

 if ( $result->is_plan ) { ... }

if the above evaluates as true, then the following methods will be available on the $result object. ✨

`plan`

 if ( $result->is_plan ) {
    print $result->plan;
 }

this is merely a synonym for as_string.

`directive`

 my $directive = $result->directive;

if a SKIP directive is included with the plan, this method will return it.

1..0 # SKIP: why bother?

`explanation`

 my $explanation = $result->explanation;

if a SKIP directive was included with the plan, this method will return the explanation, if any.

"pragma" methods

 if ( $result->is_pragma ) { ... }

if the above evaluates as true, then the following methods will be available on the $result object.

`pragmas`

returns a list of pragmas, each of which is a + or - followed by the pragma name.

"comment" methods

 if ( $result->is_comment ) { ... }

if the above evaluates as true, then the following methods will be available on the $result object.

`comment`

 if ( $result->is_comment ) {
     my $comment = $result->comment;
     print "I have something to say:  $comment";
 }

"bailout" methods

 if ( $result->is_bailout ) { ... }

if the above evaluates as true, then the following methods will be available on the $result object.

`explanation`

 if ( $result->is_bailout ) {
     my $explanation = $result->explanation;
     print "We bailed out because ($explanation)";
 }

if, and only if, a token is a bailout token, you can get an explanation via this method. the explanation is the text after the mystical Bail out! words which appear in the tap output. ✨

"unknown" methods

 if ( $result->is_unknown ) { ... }

there are no unique methods for unknown results. that's it, that's the section. 🫶

"test" methods

 if ( $result->is_test ) { ... }

if the above evaluates as true, then the following methods will be available on the $result object.

`ok`

 my $ok = $result->ok;

returns the literal text of the ok or not ok status.

`number`

 my $test_number = $result->number;

returns the number of the test, even if the original TAP output did not supply that number. we're filling in the blanks for you, bestie. 🎀

`description`

 my $description = $result->description;

returns the description of the test, if any. this is the portion after the test number but before the directive.

`directive`

 my $directive = $result->directive;

returns either TODO or SKIP if either directive was present for a test line.

`explanation`

 my $explanation = $result->explanation;

if a test had either a TODO or SKIP directive, this method will return the accompanying explanation, if present.

not ok 17 - 'Pigs can fly' # TODO not enough acid

for the above line, the explanation is not enough acid.

`is_ok`

 if ( $result->is_ok ) { ... }

returns a boolean value indicating whether or not the test passed. remember that for TODO tests, the test always passes. 👑

note: this was formerly passed. the latter method is deprecated and will issue a warning.

`is_actual_ok`

 if ( $result->is_actual_ok ) { ... }

returns a boolean value indicating whether or not the test passed, regardless of its TODO status.

note: this was formerly actual_passed. the latter method is deprecated and will issue a warning.

`is_unplanned`

 if ( $test->is_unplanned ) { ... }

if a test number is greater than the number of planned tests, this method will return true. unplanned tests will always return false for is_ok, regardless of whether or not the test has_todo (see TAP::Parser::Result::Test for more information about this). it's giving unhinged, honestly. 😭

`has_skip`

 if ( $result->has_skip ) { ... }

returns a boolean value indicating whether or not this test had a SKIP directive.

`has_todo`

 if ( $result->has_todo ) { ... }

returns a boolean value indicating whether or not this test had a TODO directive.

note that TODO tests always pass. if you need to know whether or not they really passed, check the is_actual_ok method instead, okay?

`in_todo`

 if ( $parser->in_todo ) { ... }

true while the most recent result was a TODO. becomes true before the TODO result is returned and stays true until just before the next non-TODO test is returned. literally the main character of state flags. 💅

✨ Pragmas ✨

`pragma`

Grab or set a pragma, bestie 💅. Wanna check what a pragma's doing right now?

if ( $p->pragma('strict') ) {
    # be strict
}

And to set one:

$p->pragma('strict', 1); # enable strict mode

`pragmas`

Wanna see literally every pragma that's currently switched on? She'll hand you the whole list:

my @pragmas_enabled = $p->pragmas;

✨ Summary Results ✨

These ones? Total "meta" tea ☕ — big-picture info about the whole test program, not about any one single test.

`plan`

my $plan = $parser->plan;

Returns the test plan, if one was found. 👑

`good_plan`

Deprecated, babe 😭. Use is_good_plan instead.

`is_good_plan`

if ( $parser->is_good_plan ) { ... }

Hands you back a true/false value: does the number of tests planned match the number of tests run? vibe check passed or vibe check failed, that's the whole question.

Note: this used to be called good_plan. That old name is deprecated and will throw a warning at you, so don't use it.

And since we're on that subject ...

`tests_planned`

print $parser->tests_planned;

Returns how many tests were planned, according to the plan. So a plan of '1..17' means 17 tests were planned. 🔢

`tests_run`

print $parser->tests_run;

Returns how many tests actually ran. Hopefully that matches $parser->tests_planned. 🤞

`skip_all`

Returns a true value — actually, it returns the reason for the skipping — if all the tests were skipped.

`start_time`

Returns the wall-clock time when the Parser was created.

`end_time`

Returns the wall-clock time when the end of TAP input was seen.

`start_times`

Returns the CPU times (like times in perlfunc) when the Parser was created.

`end_times`

Returns the CPU times (like times in perlfunc) when the end of TAP input was seen.

`has_problems`

if ( $parser->has_problems ) {
    ...
}

This is the 'catch-all' girlie 🚨 — she returns true if any tests have currently failed, any TODO tests unexpectedly succeeded, or any parse errors occurred. Any one of those and it's a yes.

`version`

$parser->version;

Once the parser is done, this returns the version number of the parsed TAP. Version numbers got introduced with TAP version 13, so if no version number turns up anywhere, version 12 is assumed.

`exit`

$parser->exit;

Once the parser is done, this returns the exit status. And if the parser ran an executable, you get the exit status of that executable.

`wait`

$parser->wait;

Once the parser is done, this returns the wait status. Run an executable through the parser and you get that executable's wait status. Otherwise it just returns the exit status. Simple as. 💖

`ignore_exit`

$parser->ignore_exit(1);

Tells the parser to ignore the exit status from the test when it's figuring out whether the test passed. Normally, tests with a non-zero exit status count as failed even if every individual test passed 😤. So in cases where you can't control the exit value of the test script, use this option to ignore it.

`parse_errors`

my @errors = $parser->parse_errors; # the parser errors
my $errors = $parser->parse_errors; # the number of parser_errors

Okay so fortunately, all TAP output is perfect ✨. In the event that it is not, this method returns the parser errors. Note that a junk line which the parser doesn't recognize is not an error — this allows this parser to handle future versions of TAP. Here are all the TAP errors the parser reports:

Misplaced plan — the plan (for example, '1..5'), must only come at the beginning or end of the TAP output.
No plan — gotta have a plan!
More than one plan — look:

1..3
ok 1 - input file opened
not ok 2 - first line of the input valid # todo some data
ok 3 read the rest of the file
1..3

Right. Very funny. Don't do that. 💀

Test numbers out of sequence — check it:

1..3
ok 1 - input file opened
not ok 2 - first line of the input valid # todo some data
ok 2 read the rest of the file

That last test line above should have the number '3' instead of '2'.

Note that it's perfectly acceptable for some lines to have test numbers and others to not have them. However, when a test number is found, it must be in sequence. The following is also an error:

1..3
ok 1 - input file opened
not ok - first line of the input valid # todo some data
ok 2 read the rest of the file

But this is not:

1..3
ok  - input file opened
not ok - first line of the input valid # todo some data
ok 3 read the rest of the file

`get_select_handles`

Get a list of file handles which can be passed to select to determine the readiness of this parser. 👀

`delete_spool`

Delete and return the spool.

my $fh = $parser->delete_spool;

✨ CALLBACKS ✨

Like I mentioned earlier, a callback key can be added to the TAP::Parser constructor. If it's there, then every callback corresponding to a given result type gets called with the result as the argument — that's if you use the run method. The callback is expected to be a subroutine reference (or an anonymous subroutine) which is invoked with the parser result as its argument. 🎀

my %callbacks = (
    test    => \&test_callback,
    plan    => \&plan_callback,
    comment => \&comment_callback,
    bailout => \&bailout_callback,
    unknown => \&unknown_callback,
);

my $aggregator = TAP::Parser::Aggregator->new;
for my $file ( @test_files ) {
    my $parser = TAP::Parser->new(
        {
            source    => $file,
            callbacks => \%callbacks,
        }
    );
    $parser->run;
    $aggregator->add( $file, $parser );
}

Callbacks can also be added like this:

$parser->callback( test => \&test_callback );
$parser->callback( plan => \&plan_callback );

The following keys are allowed for callbacks. These keys are case-sensitive. 🔑

test — invoked if $result->is_test returns true.
version — invoked if $result->is_version returns true.
plan — invoked if $result->is_plan returns true.
comment — invoked if $result->is_comment returns true.
bailout — invoked if $result->is_unknown returns true.
yaml — invoked if $result->is_yaml returns true.
unknown — invoked if $result->is_unknown returns true.
ELSE — if a result doesn't have a callback defined for it, this callback gets invoked. So if all of the previous result types are specified as callbacks, this one will literally never get invoked. 🙈
ALL — this callback always gets invoked, and it happens for each result after one of the above callbacks is invoked. For example, if Term::ANSIColor is loaded, you could use the following to color your test output:

my %callbacks = (
    test => sub {
        my $test = shift;
        if ( $test->is_ok && not $test->directive ) {
            # normal passing test
            print color 'green';
        }
        elsif ( !$test->is_ok ) {    # even if it's TODO
            print color 'white on_red';
        }
        elsif ( $test->has_skip ) {
            print color 'white on_blue';

        }
        elsif ( $test->has_todo ) {
            print color 'white';
        }
    },
    ELSE => sub {
        # plan, comment, and so on (anything which isn't a test line)
        print color 'black on_white';
    },
    ALL => sub {
        # now print them
        print shift->as_string;
        print color 'reset';
        print "\n";
    },
);

EOF — invoked when there are no more lines to be parsed. Since there's no accompanying TAP::Parser::Result object, the TAP::Parser object gets passed instead.

✨ TAP GRAMMAR ✨

If you're looking for an EBNF grammar, see TAP::Parser::Grammar. 📚

💫 BACKWARDS COMPATIBILITY 💫

okay so the Perl-QA list tried so hard to keep things backwards compatible with Test::Harness, bestie. They really did. But there are some minor differences, and we gotta talk about them. 🫶

🌸 Differences 🌸

TODO plans

So there's this little-known feature of Test::Harness — it supported TODO lists in the plan itself, which is wild:

1..2 todo 2
ok 1 - We have liftoff
not ok 2 - Anti-gravity device activated

Under Test::Harness, test number 2 would pass because it was listed as a TODO test on the plan line. But — and here's the thing — we are not aware of anyone actually using this feature, and hard-coding test numbers is discouraged because it's very easy to add a test and break the test number sequence. This makes test suites very fragile. 😭 Fragile test suites are NOT the vibe.

Instead, the following should be used:

1..2
ok 1 - We have liftoff
not ok 2 - Anti-gravity device activated # TODO

periodt. do it this way. 💅

'Missing' tests

It rarely happens, but sometimes a harness might encounter 'missing tests':

ok 1
ok 2
ok 15
ok 16
ok 17

Test::Harness would report tests 3-14 as having failed. For the TAP::Parser, though, these tests are not considered failed because they've never run. They're reported as parse failures (tests out of sequence). So like... they didn't fail, they just never showed up to the party. 🙈

🧬 SUBCLASSING 🧬

If you find you need to provide custom functionality (as you would have using Test::Harness::Straps), you're in luck: TAP::Parser and friends are designed to be easily plugged-into and/or subclassed. iconic design honestly. 👑

Before you start, it's important to know a few things:

All TAP::* objects inherit from TAP::Object.
Many TAP::* classes have a SUBCLASSING section to guide you.
Note that TAP::Parser is designed to be the central "maker" — ie: it is responsible for creating most new objects in the TAP::Parser::* namespace.

This makes it possible for you to have a single point of configuring what subclasses should be used, which means that in many cases you'll find you only need to sub-class one of the parser's components. main character efficiency, fr fr. ✨

The exception to this rule are SourceHandlers & Iterators, but those are both created with customizable IteratorFactory.

By subclassing, you may end up overriding undocumented methods. That's not a bad thing per se, but be forewarned that undocumented methods may change without warning from one release to the next — we cannot guarantee backwards compatibility. If any documented method needs changing, it will be deprecated first, and changed in a later release.

⚠️ lowkey important: undocumented methods are fair game for breaking changes. documented ones get deprecated first. know the difference, bestie.

🎀 Parser Components 🎀

🔥 Sources

A TAP parser consumes input from a single raw source of TAP, which could come from anywhere (a file, an executable, a database, an IO handle, a URI, etc..). The source gets bundled up in a TAP::Parser::Source object which gathers some meta data about it. The parser then uses a TAP::Parser::IteratorFactory to determine which TAP::Parser::SourceHandler to use to turn the raw source into a stream of TAP by way of "Iterators".

If you simply want TAP::Parser to handle a new source of TAP you probably don't need to subclass TAP::Parser itself. Rather, you'll need to create a new TAP::Parser::SourceHandler class, and just plug it into the parser using the sources param to new. Before you start writing one, read through TAP::Parser::IteratorFactory to get a feel for how the system works first. do your homework bestie, it pays off. 📚

If you find you really need to use your own iterator factory you can still do so without sub-classing TAP::Parser by setting iterator_factory_class.

If you just need to customize the objects on creation, subclass TAP::Parser and override make_iterator_factory.

💀 Note that make_source & make_perl_source have been DEPRECATED and are now removed.

🦋 Iterators

A TAP parser uses iterators to loop through the stream of TAP read in from the source it was given. There are a few types of Iterators available by default, all sub-classes of TAP::Parser::Iterator. Choosing which iterator to use is the responsibility of the iterator factory, though it simply delegates to the Source Handler it uses.

If you're writing your own TAP::Parser::SourceHandler, you may need to create your own iterators too. If so you'll need to subclass TAP::Parser::Iterator.

💀 Note that make_iterator has been DEPRECATED and is now removed.

🌈 Results

A TAP parser creates TAP::Parser::Results as it iterates through the input stream. There are quite a few result types available; choosing which class to use is the responsibility of the result factory.

To create your own result types you have two options:

option 1

Subclass TAP::Parser::Result and register your new result type/class with the default TAP::Parser::ResultFactory.

option 2

Subclass TAP::Parser::ResultFactory itself and implement your own TAP::Parser::Result creation logic. Then you'll need to customize the class used by your parser by setting the result_factory_class parameter. See "new" for more details.

If you need to customize the objects on creation, subclass TAP::Parser and override make_result.

💜 Grammar

TAP::Parser::Grammar is the heart of the parser. 🫀 It tokenizes the TAP input stream and produces results. If you need to customize its behaviour you should probably familiarize yourself with the source first. Enough lecturing.

Subclass TAP::Parser::Grammar and customize your parser by setting the grammar_class parameter. See "new" for more details.

If you need to customize the objects on creation, subclass TAP::Parser and override make_grammar.

🫶 ACKNOWLEDGMENTS 🫶

All of the following have helped. Bug reports, patches, (im)moral support, or just words of encouragement have all been forthcoming. shoutout to every single one of them, they ate. 🍓

Michael Schwern
Andy Lester
chromatic
GEOFFR
Shlomi Fish
Torsten Schoenfeld
Jerry Gay
Aristotle
Adam Kennedy
Yves Orton
Adrian Howard
Sean & Lil
Andreas J. Koenig
Florian Ragwitz
Corion
Mark Stosberg
Matt Kraai
David Wheeler
Alex Vandiver
Cosimo Streppone
Ville Skyttä

👑 AUTHORS 👑

Curtis "Ovid" Poe <ovid@cpan.org>

Andy Armstong <andy@hexten.net>

Eric Wilhelm @ <ewilhelm at cpan dot org>

Michael Peters <mpeters at plusthree dot com>

Leif Eriksen <leif dot eriksen at bigpond dot com>

Steve Purkis <spurkis@cpan.org>

Nicholas Clark <nick@ccl4.org>

Lee Johnson <notfadeaway at btinternet dot com>

Philippe Bruhat <book@cpan.org>

🐛 BUGS 🐛

Please report any bugs or feature requests to bug-test-harness@rt.cpan.org, or through the web interface at <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Harness>. We will be notified, and then you'll automatically be notified of progress on your bug as we make changes. teamwork makes the dream work. 🌸

Obviously, bugs which include patches are best. If you prefer, you can patch against bleed by via anonymous checkout of the latest version:

git clone git://github.com/Perl-Toolchain-Gang/Test-Harness.git

⭐ COPYRIGHT & LICENSE ⭐

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

okay that's the whole page bestie, you made it to the end 🎉 this was TAP::Parser(3perl) from perl v5.44.0, dated 2026-10-17 — go forth and parse some TAP, you absolute legend 💅✨🦋

📦 where this page comes from

arch rolling: perl 5.44.0-1 · Artistic-1.0-Perl AND GPL-1.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms