TAP::Harness::Beyond(3p) Perl Programmers Reference Guide

TAP::Harness::Beyond(3p) Perl Programmers Reference Guide #

TAP::Harness::Beyond(3p) Perl Programmers Reference Guide

NNAAMMEE #

 Test::Harness::Beyond - Beyond make test

BBeeyyoonndd mmaakkee tteesstt Test::Harness is responsible for running test scripts, analysing their output and reporting success or failure. When I type _m_a_k_e _t_e_s_t (or _._/_B_u_i_l_d _t_e_s_t) for a module, Test::Harness is usually used to run the tests (not all modules use Test::Harness but the majority do).

 To start exploring some of the features of Test::Harness I need to switch
 from _m_a_k_e _t_e_s_t to the _p_r_o_v_e command (which ships with Test::Harness). For
 the following examples I'll also need a recent version of Test::Harness
 installed; 3.14 is current as I write.

 For the examples I'm going to assume that we're working with a 'normal'
 Perl module distribution. Specifically I'll assume that typing _m_a_k_e or
 _._/_B_u_i_l_d causes the built, ready-to-install module code to be available
 below ./blib/lib and ./blib/arch and that there's a directory called 't'
 that contains our tests. Test::Harness isn't hardwired to that
 configuration but it  saves me from explaining which files live where for
 each example.

 Back to _p_r_o_v_e; like _m_a_k_e _t_e_s_t it runs a test suite - but it provides far
 more control over which tests are executed, in what order and how their
 results are reported. Typically _m_a_k_e _t_e_s_t runs all the test scripts below
 the 't' directory. To do the same thing with prove I type:

   prove -rb t

 The switches here are -r to recurse into any directories below 't' and -b
 which adds ./blib/lib and ./blib/arch to Perl's include path so that the
 tests can find the code they will be testing. If I'm testing a module of
 which an earlier version is already installed I need to be careful about
 the include path to make sure I'm not running my tests against the
 installed version rather than the new one that I'm working on.

 Unlike _m_a_k_e _t_e_s_t, typing _p_r_o_v_e doesn't automatically rebuild my module.
 If I forget to make before prove I will be testing against older versions
 of those files - which inevitably leads to confusion.  I either get into
 the habit of typing

   make && prove -rb t

 or - if I have no XS code that needs to be built I use the modules below
 _l_i_b instead

   prove -Ilib -r t

 So far I've shown you nothing that _m_a_k_e _t_e_s_t doesn't do. Let's fix that.

SSaavveedd SSttaattee If I have failing tests in a test suite that consists of more than a handful of scripts and takes more than a few seconds to run it rapidly becomes tedious to run the whole test suite repeatedly as I track down the problems.

 I can tell prove just to run the tests that are failing like this:

   prove -b t/this_fails.t t/so_does_this.t

 That speeds things up but I have to make a note of which tests are
 failing and make sure that I run those tests. Instead I can use prove's
 --state switch and have it keep track of failing tests for me. First I do
 a complete run of the test suite and tell prove to save the results:

   prove -rb --state=save t

 That stores a machine readable summary of the test run in a file called
 '.prove' in the current directory. If I have failures I can then run just
 the failing scripts like this:

   prove -b --state=failed

 I can also tell prove to save the results again so that it updates its
 idea of which tests failed:

   prove -b --state=failed,save

 As soon as one of my failing tests passes it will be removed from the
 list of failed tests. Eventually I fix them all and prove can find no
 failing tests to run:

   Files=0, Tests=0, 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)
   Result: NOTESTS

 As I work on a particular part of my module it's most likely that the
 tests that cover that code will fail. I'd like to run the whole test
 suite but have it prioritize these 'hot' tests. I can tell prove to do
 this:

   prove -rb --state=hot,save t

 All the tests will run but those that failed most recently will be run
 first. If no tests have failed since I started saving state all tests
 will run in their normal order. This combines full test coverage with
 early notification of failures.

 The --state switch supports a number of options; for example to run
 failed tests first followed by all remaining tests ordered by the
 timestamps of the test scripts - and save the results - I can use

   prove -rb --state=failed,new,save t

 See the prove documentation (type prove --man) for the full list of state
 options.

 When I tell prove to save state it writes a file called '.prove'
 ('_prove' on Windows) in the current directory. It's a YAML document so
 it's quite easy to write tools of your own that work on the saved test
 state - but the format isn't officially documented so it might change
 without (much) warning in the future.

PPaarraalllleell TTeessttiinngg If my tests take too long to run I may be able to speed them up by running multiple test scripts in parallel. This is particularly effective if the tests are I/O bound or if I have multiple CPU cores. I tell prove to run my tests in parallel like this:

   prove -rb -j 9 t

 The -j switch enables parallel testing; the number that follows it is the
 maximum number of tests to run in parallel. Sometimes tests that pass
 when run sequentially will fail when run in parallel. For example if two
 different test scripts use the same temporary file or attempt to listen
 on the same socket I'll have problems running them in parallel. If I see
 unexpected failures I need to check my tests to work out which of them
 are trampling on the same resource and rename temporary files or add
 locks as appropriate.

 To get the most performance benefit I want to have the test scripts that
 take the longest to run start first - otherwise I'll be waiting for the
 one test that takes nearly a minute to complete after all the others are
 done. I can use the --state switch to run the tests in slowest to fastest
 order:

   prove -rb -j 9 --state=slow,save t

NNoonn--PPeerrll TTeessttss The Test Anything Protocol (http://testanything.org/) isn’t just for Perl. Just about any language can be used to write tests that output TAP. There are TAP based testing libraries for C, C++, PHP, Python and many others. If I can’t find a TAP library for my language of choice it’s easy to generate valid TAP. It looks like this:

   1..3
   ok 1 - init OK
   ok 2 - opened file
   not ok 3 - appended to file

 The first line is the plan - it specifies the number of tests I'm going
 to run so that it's easy to check that the test script didn't exit before
 running all the expected tests. The following lines are the test results
 - 'ok' for pass, 'not ok' for fail. Each test has a number and,
 optionally, a description. And that's it. Any language that can produce
 output like that on STDOUT can be used to write tests.

 Recently I've been rekindling a two-decades-old interest in Forth.
 Evidently I have a masochistic streak that even Perl can't satisfy.  I
 want to write tests in Forth and run them using prove (you can find my
 gforth TAP experiments at https://svn.hexten.net/andy/Forth/Testing/). I
 can use the --exec switch to tell prove to run the tests using gforth
 like this:

   prove -r --exec gforth t

 Alternately, if the language used to write my tests allows a shebang line
 I can use that to specify the interpreter. Here's a test written in PHP:

   #!/usr/bin/php
   <?php
     print "1..2\n";
     print "ok 1\n";
     print "not ok 2\n";
   ?>

 If I save that as t/phptest.t the shebang line will ensure that it runs
 correctly along with all my other tests.

MMiixxiinngg iitt uupp Subtle interdependencies between test programs can mask problems - for example an earlier test may neglect to remove a temporary file that affects the behaviour of a later test. To find this kind of problem I use the –shuffle and –reverse options to run my tests in random or reversed order.

RRoolllliinngg MMyy OOwwnn If I need a feature that prove doesn’t provide I can easily write my own.

 Typically you'll want to change how TAP gets _i_n_p_u_t into and _o_u_t_p_u_t from
 the parser.  App::Prove supports arbitrary plugins, and TAP::Harness
 supports custom _f_o_r_m_a_t_t_e_r_s and _s_o_u_r_c_e _h_a_n_d_l_e_r_s that you can load using
 either prove or Module::Build; there are many examples to base mine on.
 For more details see App::Prove, TAP::Parser::SourceHandler, and
 TAP::Formatter::Base.

 If writing a plugin is not enough, you can write your own test harness;
 one of the motives for the 3.00 rewrite of Test::Harness was to make it
 easier to subclass and extend.

 The Test::Harness module is a compatibility wrapper around TAP::Harness.
 For new applications I should use TAP::Harness directly. As we'll see,
 prove uses TAP::Harness.

 When I run prove it processes its arguments, figures out which test
 scripts to run and then passes control to TAP::Harness to run the tests,
 parse, analyse and present the results. By subclassing TAP::Harness I can
 customise many aspects of the test run.

 I want to log my test results in a database so I can track them over
 time. To do this I override the summary method in TAP::Harness.  I start
 with a simple prototype that dumps the results as a YAML document:

   package My::TAP::Harness;

   use base 'TAP::Harness';
   use YAML;

   sub summary {
     my ( $self, $aggregate ) = @_;
     print Dump( $aggregate );
     $self->SUPER::summary( $aggregate );
   }

   1;

 I need to tell prove to use my My::TAP::Harness. If My::TAP::Harness is
 on Perl's @INC include path I can

   prove --harness=My::TAP::Harness -rb t

 If I don't have My::TAP::Harness installed on @INC I need to provide the
 correct path to perl when I run prove:

   perl -Ilib `which prove` --harness=My::TAP::Harness -rb t

 I can incorporate these options into my own version of prove. It's pretty
 simple. Most of the work of prove is handled by App::Prove.  The
 important code in prove is just:

   use App::Prove;

   my $app = App::Prove->new;
   $app->process_args(@ARGV);
   exit( $app->run ? 0 : 1 );

 If I write a subclass of App::Prove I can customise any aspect of the
 test runner while inheriting all of prove's behaviour. Here's myprove:

   #!/usr/bin/env perl use lib qw( lib );      # Add ./lib to @INC
   use App::Prove;

   my $app = App::Prove->new;

   # Use custom TAP::Harness subclass
   $app->harness( 'My::TAP::Harness' );

   $app->process_args( @ARGV ); exit( $app->run ? 0 : 1 );

 Now I can run my tests like this

   ./myprove -rb t

DDeeeeppeerr CCuussttoommiissaattiioonn Now that I know how to subclass and replace TAP::Harness I can replace any other part of the harness. To do that I need to know which classes are responsible for which functionality. Here’s a brief guided tour; the default class for each component is shown in parentheses. Normally any replacements I write will be subclasses of these default classes.

 When I run my tests TAP::Harness creates a scheduler
 (TAP::Parser::Scheduler) to work out the running order for the tests, an
 aggregator (TAP::Parser::Aggregator) to collect and analyse the test
 results and a formatter (TAP::Formatter::Console) to display those
 results.

 If I'm running my tests in parallel there may also be a multiplexer
 (TAP::Parser::Multiplexer) - the component that allows multiple tests to
 run simultaneously.

 Once it has created those helpers TAP::Harness starts running the tests.
 For each test it creates a new parser (TAP::Parser) which is responsible
 for running the test script and parsing its output.

 To replace any of these components I call one of these harness methods
 with the name of the replacement class:

   aggregator_class
   formatter_class
   multiplexer_class
   parser_class
   scheduler_class

 For example, to replace the aggregator I would

   $harness->aggregator_class( 'My::Aggregator' );

 Alternately I can supply the names of my substitute classes to the
 TAP::Harness constructor:

   my $harness = TAP::Harness->new(
     { aggregator_class => 'My::Aggregator' }
   );

 If I need to reach even deeper into the internals of the harness I can
 replace the classes that TAP::Parser uses to execute test scripts and
 tokenise their output. Before running a test script TAP::Parser creates a
 grammar (TAP::Parser::Grammar) to decode the raw TAP into tokens, a
 result factory (TAP::Parser::ResultFactory) to turn the decoded TAP
 results into objects and, depending on whether it's running a test script
 or reading TAP from a file, scalar or array a source or an iterator
 (TAP::Parser::IteratorFactory).

 Each of these objects may be replaced by calling one of these parser
 methods:

   source_class
   perl_source_class
   grammar_class
   iterator_factory_class
   result_factory_class

CCaallllbbaacckkss As an alternative to subclassing the components I need to change I can attach callbacks to the default classes. TAP::Harness exposes these callbacks:

   parser_args      Tweak the parameters used to create the parser
   made_parser      Just made a new parser
   before_runtests  About to run tests
   after_runtests   Have run all tests
   after_test       Have run an individual test script

 TAP::Parser also supports callbacks; bailout, comment, plan, test,
 unknown, version and yaml are called for the corresponding TAP result
 types, ALL is called for all results, ELSE is called for all results for
 which a named callback is not installed and EOF is called once at the end
 of each TAP stream.

 To install a callback I pass the name of the callback and a subroutine
 reference to TAP::Harness or TAP::Parser's callback method:

   $harness->callback( after_test => sub {
     my ( $script, $desc, $parser ) = @_;
   } );

 I can also pass callbacks to the constructor:

   my $harness = TAP::Harness->new({
     callbacks => {
             after_test => sub {
         my ( $script, $desc, $parser ) = @_;
         # Do something interesting here
             }
     }
   });

 When it comes to altering the behaviour of the test harness there's more
 than one way to do it. Which way is best depends on my requirements. In
 general if I only want to observe test execution without changing the
 harness' behaviour (for example to log test results to a database) I
 choose callbacks. If I want to make the harness behave differently
 subclassing gives me more control.

PPaarrssiinngg TTAAPP Perhaps I don’t need a complete test harness. If I already have a TAP test log that I need to parse all I need is TAP::Parser and the various classes it depends upon. Here’s the code I need to run a test and parse its TAP output

   use TAP::Parser;

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

 Alternately I can pass an open filehandle as source and have the parser
 read from that rather than attempting to run a test script:

   open my $tap, '<', 'tests.tap'
     or die "Can't read TAP transcript ($!)\n";
   my $parser = TAP::Parser->new( { source => $tap } );
   while ( my $result = $parser->next ) {
     print $result->as_string, "\n";
   }

 This approach is useful if I need to convert my TAP based test results
 into some other representation. See TAP::Convert::TET
 (http://search.cpan.org/dist/TAP-Convert-TET/) for an example of this
 approach.

GGeettttiinngg SSuuppppoorrtt The Test::Harness developers hang out on the tapx-dev mailing list[1]. For discussion of general, language independent TAP issues there’s the tap-l[2] list. Finally there’s a wiki dedicated to the Test Anything Protocol[3]. Contributions to the wiki, patches and suggestions are all welcome.

 [1] <http://www.hexten.net/mailman/listinfo/tapx-dev> [2]
 <http://testanything.org/mailman/listinfo/tap-l> [3]
 <http://testanything.org/>

perl v5.36.3 2017-02-05 TAP::Harness::Beyond(3p)