{
    "mode": "perldoc",
    "parameter": "TAP::Harness::Beyond",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/TAP%3A%3AHarness%3A%3ABeyond/json",
    "generated": "2026-06-15T16:04:17Z",
    "sections": {
        "NAME": {
            "content": "Test::Harness::Beyond - Beyond make test\n",
            "subsections": []
        },
        "Beyond make test": {
            "content": "Test::Harness is responsible for running test scripts, analysing their output and reporting\nsuccess or failure. When I type make test (or ./Build test) for a module, Test::Harness is\nusually used to run the tests (not all modules use Test::Harness but the majority do).\n\nTo start exploring some of the features of Test::Harness I need to switch from make test to the\nprove command (which ships with Test::Harness). For the following examples I'll also need a\nrecent version of Test::Harness installed; 3.14 is current as I write.\n\nFor the examples I'm going to assume that we're working with a 'normal' Perl module\ndistribution. Specifically I'll assume that typing make or ./Build causes the built,\nready-to-install module code to be available below ./blib/lib and ./blib/arch and that there's a\ndirectory called 't' that contains our tests. Test::Harness isn't hardwired to that\nconfiguration but it saves me from explaining which files live where for each example.\n\nBack to prove; like make test it runs a test suite - but it provides far more control over which\ntests are executed, in what order and how their results are reported. Typically make test runs\nall the test scripts below the 't' directory. To do the same thing with prove I type:\n\nprove -rb t\n\nThe switches here are -r to recurse into any directories below 't' and -b which adds ./blib/lib\nand ./blib/arch to Perl's include path so that the tests can find the code they will be testing.\nIf I'm testing a module of which an earlier version is already installed I need to be careful\nabout the include path to make sure I'm not running my tests against the installed version\nrather than the new one that I'm working on.\n\nUnlike make test, typing prove doesn't automatically rebuild my module. If I forget to make\nbefore prove I will be testing against older versions of those files - which inevitably leads to\nconfusion. I either get into the habit of typing\n\nmake && prove -rb t\n\nor - if I have no XS code that needs to be built I use the modules below lib instead\n\nprove -Ilib -r t\n\nSo far I've shown you nothing that make test doesn't do. Let's fix that.\n",
            "subsections": [
                {
                    "name": "Saved State",
                    "content": "If I have failing tests in a test suite that consists of more than a handful of scripts and\ntakes more than a few seconds to run it rapidly becomes tedious to run the whole test suite\nrepeatedly as I track down the problems.\n\nI can tell prove just to run the tests that are failing like this:\n\nprove -b t/thisfails.t t/sodoesthis.t\n\nThat speeds things up but I have to make a note of which tests are failing and make sure that I\nrun those tests. Instead I can use prove's --state switch and have it keep track of failing\ntests for me. First I do a complete run of the test suite and tell prove to save the results:\n\nprove -rb --state=save t\n\nThat stores a machine readable summary of the test run in a file called '.prove' in the current\ndirectory. If I have failures I can then run just the failing scripts like this:\n\nprove -b --state=failed\n\nI can also tell prove to save the results again so that it updates its idea of which tests\nfailed:\n\nprove -b --state=failed,save\n\nAs soon as one of my failing tests passes it will be removed from the list of failed tests.\nEventually I fix them all and prove can find no failing tests to run:\n\nFiles=0, Tests=0, 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)\nResult: NOTESTS\n\nAs I work on a particular part of my module it's most likely that the tests that cover that code\nwill fail. I'd like to run the whole test suite but have it prioritize these 'hot' tests. I can\ntell prove to do this:\n\nprove -rb --state=hot,save t\n\nAll the tests will run but those that failed most recently will be run first. If no tests have\nfailed since I started saving state all tests will run in their normal order. This combines full\ntest coverage with early notification of failures.\n\nThe --state switch supports a number of options; for example to run failed tests first followed\nby all remaining tests ordered by the timestamps of the test scripts - and save the results - I\ncan use\n\nprove -rb --state=failed,new,save t\n\nSee the prove documentation (type prove --man) for the full list of state options.\n\nWhen I tell prove to save state it writes a file called '.prove' ('prove' on Windows) in the\ncurrent directory. It's a YAML document so it's quite easy to write tools of your own that work\non the saved test state - but the format isn't officially documented so it might change without\n(much) warning in the future.\n"
                },
                {
                    "name": "Parallel Testing",
                    "content": "If my tests take too long to run I may be able to speed them up by running multiple test scripts\nin parallel. This is particularly effective if the tests are I/O bound or if I have multiple CPU\ncores. I tell prove to run my tests in parallel like this:\n\nprove -rb -j 9 t\n\nThe -j switch enables parallel testing; the number that follows it is the maximum number of\ntests to run in parallel. Sometimes tests that pass when run sequentially will fail when run in\nparallel. For example if two different test scripts use the same temporary file or attempt to\nlisten on the same socket I'll have problems running them in parallel. If I see unexpected\nfailures I need to check my tests to work out which of them are trampling on the same resource\nand rename temporary files or add locks as appropriate.\n\nTo get the most performance benefit I want to have the test scripts that take the longest to run\nstart first - otherwise I'll be waiting for the one test that takes nearly a minute to complete\nafter all the others are done. I can use the --state switch to run the tests in slowest to\nfastest order:\n\nprove -rb -j 9 --state=slow,save t\n"
                },
                {
                    "name": "Non-Perl Tests",
                    "content": "The Test Anything Protocol (http://testanything.org/) isn't just for Perl. Just about any\nlanguage can be used to write tests that output TAP. There are TAP based testing libraries for\nC, C++, PHP, Python and many others. If I can't find a TAP library for my language of choice\nit's easy to generate valid TAP. It looks like this:\n\n1..3\nok 1 - init OK\nok 2 - opened file\nnot ok 3 - appended to file\n\nThe first line is the plan - it specifies the number of tests I'm going to run so that it's easy\nto check that the test script didn't exit before running all the expected tests. The following\nlines are the test results - 'ok' for pass, 'not ok' for fail. Each test has a number and,\noptionally, a description. And that's it. Any language that can produce output like that on\nSTDOUT can be used to write tests.\n\nRecently I've been rekindling a two-decades-old interest in Forth. Evidently I have a\nmasochistic streak that even Perl can't satisfy. I want to write tests in Forth and run them\nusing prove (you can find my gforth TAP experiments at\nhttps://svn.hexten.net/andy/Forth/Testing/). I can use the --exec switch to tell prove to run\nthe tests using gforth like this:\n\nprove -r --exec gforth t\n\nAlternately, if the language used to write my tests allows a shebang line I can use that to\nspecify the interpreter. Here's a test written in PHP:\n\n#!/usr/bin/php\n<?php\nprint \"1..2\\n\";\nprint \"ok 1\\n\";\nprint \"not ok 2\\n\";\n?>\n\nIf I save that as t/phptest.t the shebang line will ensure that it runs correctly along with all\nmy other tests.\n"
                },
                {
                    "name": "Mixing it up",
                    "content": "Subtle interdependencies between test programs can mask problems - for example an earlier test\nmay neglect to remove a temporary file that affects the behaviour of a later test. To find this\nkind of problem I use the --shuffle and --reverse options to run my tests in random or reversed\norder.\n"
                },
                {
                    "name": "Rolling My Own",
                    "content": "If I need a feature that prove doesn't provide I can easily write my own.\n\nTypically you'll want to change how TAP gets *input* into and *output* from the parser.\nApp::Prove supports arbitrary plugins, and TAP::Harness supports custom *formatters* and *source\nhandlers* that you can load using either prove or Module::Build; there are many examples to base\nmine on. For more details see App::Prove, TAP::Parser::SourceHandler, and TAP::Formatter::Base.\n\nIf writing a plugin is not enough, you can write your own test harness; one of the motives for\nthe 3.00 rewrite of Test::Harness was to make it easier to subclass and extend.\n\nThe Test::Harness module is a compatibility wrapper around TAP::Harness. For new applications I\nshould use TAP::Harness directly. As we'll see, prove uses TAP::Harness.\n\nWhen I run prove it processes its arguments, figures out which test scripts to run and then\npasses control to TAP::Harness to run the tests, parse, analyse and present the results. By\nsubclassing TAP::Harness I can customise many aspects of the test run.\n\nI want to log my test results in a database so I can track them over time. To do this I override\nthe summary method in TAP::Harness. I start with a simple prototype that dumps the results as a\nYAML document:\n\npackage My::TAP::Harness;\n\nuse base 'TAP::Harness';\nuse YAML;\n\nsub summary {\nmy ( $self, $aggregate ) = @;\nprint Dump( $aggregate );\n$self->SUPER::summary( $aggregate );\n}\n\n1;\n\nI need to tell prove to use my My::TAP::Harness. If My::TAP::Harness is on Perl's @INC include\npath I can\n\nprove --harness=My::TAP::Harness -rb t\n\nIf I don't have My::TAP::Harness installed on @INC I need to provide the correct path to perl\nwhen I run prove:\n\nperl -Ilib `which prove` --harness=My::TAP::Harness -rb t\n\nI can incorporate these options into my own version of prove. It's pretty simple. Most of the\nwork of prove is handled by App::Prove. The important code in prove is just:\n\nuse App::Prove;\n\nmy $app = App::Prove->new;\n$app->processargs(@ARGV);\nexit( $app->run ? 0 : 1 );\n\nIf I write a subclass of App::Prove I can customise any aspect of the test runner while\ninheriting all of prove's behaviour. Here's myprove:\n\n#!/usr/bin/env perl use lib qw( lib );      # Add ./lib to @INC\nuse App::Prove;\n\nmy $app = App::Prove->new;\n\n# Use custom TAP::Harness subclass\n$app->harness( 'My::TAP::Harness' );\n\n$app->processargs( @ARGV ); exit( $app->run ? 0 : 1 );\n\nNow I can run my tests like this\n\n./myprove -rb t\n"
                },
                {
                    "name": "Deeper Customisation",
                    "content": "Now that I know how to subclass and replace TAP::Harness I can replace any other part of the\nharness. To do that I need to know which classes are responsible for which functionality. Here's\na brief guided tour; the default class for each component is shown in parentheses. Normally any\nreplacements I write will be subclasses of these default classes.\n\nWhen I run my tests TAP::Harness creates a scheduler (TAP::Parser::Scheduler) to work out the\nrunning order for the tests, an aggregator (TAP::Parser::Aggregator) to collect and analyse the\ntest results and a formatter (TAP::Formatter::Console) to display those results.\n\nIf I'm running my tests in parallel there may also be a multiplexer (TAP::Parser::Multiplexer) -\nthe component that allows multiple tests to run simultaneously.\n\nOnce it has created those helpers TAP::Harness starts running the tests. For each test it\ncreates a new parser (TAP::Parser) which is responsible for running the test script and parsing\nits output.\n\nTo replace any of these components I call one of these harness methods with the name of the\nreplacement class:\n\naggregatorclass\nformatterclass\nmultiplexerclass\nparserclass\nschedulerclass\n\nFor example, to replace the aggregator I would\n\n$harness->aggregatorclass( 'My::Aggregator' );\n\nAlternately I can supply the names of my substitute classes to the TAP::Harness constructor:\n\nmy $harness = TAP::Harness->new(\n{ aggregatorclass => 'My::Aggregator' }\n);\n\nIf I need to reach even deeper into the internals of the harness I can replace the classes that\nTAP::Parser uses to execute test scripts and tokenise their output. Before running a test script\nTAP::Parser creates a grammar (TAP::Parser::Grammar) to decode the raw TAP into tokens, a result\nfactory (TAP::Parser::ResultFactory) to turn the decoded TAP results into objects and, depending\non whether it's running a test script or reading TAP from a file, scalar or array a source or an\niterator (TAP::Parser::IteratorFactory).\n\nEach of these objects may be replaced by calling one of these parser methods:\n\nsourceclass\nperlsourceclass\ngrammarclass\niteratorfactoryclass\nresultfactoryclass\n"
                },
                {
                    "name": "Callbacks",
                    "content": "As an alternative to subclassing the components I need to change I can attach callbacks to the\ndefault classes. TAP::Harness exposes these callbacks:\n\nparserargs      Tweak the parameters used to create the parser\nmadeparser      Just made a new parser\nbeforeruntests  About to run tests\nafterruntests   Have run all tests\naftertest       Have run an individual test script\n\nTAP::Parser also supports callbacks; bailout, comment, plan, test, unknown, version and yaml are\ncalled for the corresponding TAP result types, ALL is called for all results, ELSE is called for\nall results for which a named callback is not installed and EOF is called once at the end of\neach TAP stream.\n\nTo install a callback I pass the name of the callback and a subroutine reference to TAP::Harness\nor TAP::Parser's callback method:\n\n$harness->callback( aftertest => sub {\nmy ( $script, $desc, $parser ) = @;\n} );\n\nI can also pass callbacks to the constructor:\n\nmy $harness = TAP::Harness->new({\ncallbacks => {\naftertest => sub {\nmy ( $script, $desc, $parser ) = @;\n# Do something interesting here\n}\n}\n});\n\nWhen it comes to altering the behaviour of the test harness there's more than one way to do it.\nWhich way is best depends on my requirements. In general if I only want to observe test\nexecution without changing the harness' behaviour (for example to log test results to a\ndatabase) I choose callbacks. If I want to make the harness behave differently subclassing gives\nme more control.\n"
                },
                {
                    "name": "Parsing TAP",
                    "content": "Perhaps I don't need a complete test harness. If I already have a TAP test log that I need to\nparse all I need is TAP::Parser and the various classes it depends upon. Here's the code I need\nto run a test and parse its TAP output\n\nuse TAP::Parser;\n\nmy $parser = TAP::Parser->new( { source => 't/simple.t' } );\nwhile ( my $result = $parser->next ) {\nprint $result->asstring, \"\\n\";\n}\n\nAlternately I can pass an open filehandle as source and have the parser read from that rather\nthan attempting to run a test script:\n\nopen my $tap, '<', 'tests.tap'\nor die \"Can't read TAP transcript ($!)\\n\";\nmy $parser = TAP::Parser->new( { source => $tap } );\nwhile ( my $result = $parser->next ) {\nprint $result->asstring, \"\\n\";\n}\n\nThis approach is useful if I need to convert my TAP based test results into some other\nrepresentation. See TAP::Convert::TET (http://search.cpan.org/dist/TAP-Convert-TET/) for an\nexample of this approach.\n"
                },
                {
                    "name": "Getting Support",
                    "content": "The Test::Harness developers hang out on the tapx-dev mailing list[1]. For discussion of\ngeneral, language independent TAP issues there's the tap-l[2] list. Finally there's a wiki\ndedicated to the Test Anything Protocol[3]. Contributions to the wiki, patches and suggestions\nare all welcome.\n\n[1] <http://www.hexten.net/mailman/listinfo/tapx-dev> [2]\n<http://testanything.org/mailman/listinfo/tap-l> [3] <http://testanything.org/>\n"
                }
            ]
        }
    },
    "summary": "Test::Harness::Beyond - Beyond make test",
    "flags": [],
    "examples": [],
    "see_also": []
}