man Test::TAP::Model () - Accessible (queryable, serializable object) result collector for Test::Harness::Straps runs.
NAME
Test::TAP::Model - Accessible (queryable, serializable object) result collector for Test::Harness::Straps runs.
SYNOPSIS
use Test::TAP::Model
my $t = Test::TAP::Model->new($structure);
my @tests = $t->test_files; # objects interface
YAML::Dump($t->structure); # the same thing we made it with
$t->run_tests(qw{ t/foo.t t/bar.t }); # has a side effect of creating struct
DESCRIPTION
This module is a subclass of Test::Harness::Straps (although in an ideal world it would really use delegation).
It uses callbacks in the straps object to construct a deep structure, with all the data known about a test run accessible within.
It's purpose is to ease the processing of test data, for the purpose of generating reports, or something like that.
The niche it fills is creating a way to access test run data, both from a serialized and a real source, and to ease the querying of this data.
YEAH YEAH, WHAT IS IT GOOD FOR?
Well, you can use it to send test results, and process them into pretty reports. See Test::TAP::HTMLMatrix.
TWO INTERFACES
There are two ways to access the data in Test::TAP::Model. The complex one, which creates objects, revolves around the simpler one, which for Q&D purposes is exposed and encouraged too.
Inside the object there is a well defined deep structure, accessed as
$t->structure;
This is the simple method. It is a hash, containing some fields, and basically organizes the test results, with all the fun fun data exposed.
The second interface is documented below in METHODS, and lets you create pretty little objects from this structure, which might or might not be more convenient for your purposes.
When it's ready, that is.
HASH STRUCTURE
I hope this illustrates how the structure looks.
$structure = { test_files => $test_files,
start_time => # when the run started end_time => # ... and ended };
$test_files = [ $test_file, ... ];
$test_file = { file => "t/filename.t", results => \%results; events => $events,
# optional pre_diag => # diagnosis emitted before any test };
%results = $strap->analyze_foo();
$events = [ { type => "test", num => # the serial number of the test ok => # a boolean result => # a string useful for display todo => # a boolean line => # the output line
# pugs auxillery stuff, from the <pos:> comment pos => # the place in the test file the case is in
time => # the time this event happenned }, { type => "bailout", reason => "blah blah blah", } ..., ];
That's basically it.
OBJECT INTERFACE
The object interface is structured around three objects:
- Test::TAP::Model
- A whole run
- Test::TAP::Model::File
- A test script
- Test::TAP::Model::Subtest
- A single case in a test script
Each of these is discussed in it's respectful manpage. Here's the whole run:
METHODS
The said OOP interface
- test_files
- Returns a list of Test::TAP::Model::File objects.
- ok
- passing
- passed
- nok
- failed
- failing
- Whether all the suite was OK, or opposite.
- total_ok
- total_passed
- total_nok
- total_failed
- total_percentage
- total_ratio
- total_seen
- total_skipped
- total_todo
- total_unexpectedly_succeeded
- These methods are all rather self explanatory and either provide aggregate results based on the contained test files.
- ratio
- An alias to total_ratio.
Misc methods
- new
- Creates an empty harness. Adopts a structure. This is how you take a thawed structure and query it. Takes a list of tests and immediately runs them.
- get_tests
- A method invoked by CWrun to get a list of tests to run. This is a stub, and you should subclass it if you care.
- run
- This method runs the list of tests returned by CWget_tests. Runs these tests. Just loops, and calls analyze file, with an eval { } around it to catch bail out. Actually this is the part which does eval and calls CWstart_file and CWanalyze_file
- start_file
- This tells Test::TAP::Model that we are about to analyze a new file. This will eventually be moved into an overridden version of analyze, I think. Consider it's existence a bug.
- log_event
- This logs a new event with time stamp in the event log for the current test.
- latest_event
- Returns the hash ref to the last event, or a new one if there isn't a last event yet.
- file_class
- This method returns the class to call new on, when generating file objects in CWtest_files.
- structure
- This method returns the hash reference you can save, browse, or use to create new objects with the same date.
- log_time
- This is an accessor. If it's value is set to true, any events logged will have a time stamp added.
SERIALIZING
You can use any serializer you like (YAML, Storable, etc), to freeze CW$obj->structure, and then you can thaw it back, and pass the thawed structure to CWnew_with_struct.
You can then access the object interface normally.
This behavior is guaranteed to remain consistent, at least between similar versions of this module. This is there to simplify smoke reports.
ISA Test::Harness::Straps
Test::TAP::Model is a Test::Harness::Straps subclass. It knows to run tests on it's own. See the CWrun methods and it's friends.
However, you should see how CWrun_test gets things done beforehand. It's a bit of a hack because I'm not quite sure if Test::Harness::Straps has the proper events to encapsulate this cleanly (Gaal took care of the handlers way before I got into the picture), and I'm too lazy to check it out.
AUTHORS
This list was generated from svn log testgraph.pl and testgraph.css in the pugs repo, sorted by last name.
- •
- Michal Jurosz
- •
- Yuval Kogman <nothingmuch@woobling.org> NUFFIN
- •
- Max Maischein <corion@cpan.org> CORION
- •
- James Mastros <james@mastros.biz> JMASTROS
- •
- Scott McWhirter <scott-cpan@NOSPAMkungfuftr.com> KUNGFUFTR
- •
- putter (svn handle)
- •
- Autrijs Tang <autrijus@autrjius.org> AUTRIJUS
- •
- Gaal Yahas <gaal@forum2.org> GAAL
COPYRIGHT & LICNESE
Copyright (c) 2005 the aforementioned authors. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.