GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages
Test::TAP::Model(3) User Contributed Perl Documentation Test::TAP::Model(3)

Test::TAP::Model - DEPRECATED Use TAP::Harness, TAP::Formatter::HTML

        use Test::TAP::Model;

        my $t = Test::TAP::Model->new();

        # Test::Harness::Straps methods are available, but they aren't enough.
        # Extra book keeping is required. See the run_test method

        # here's a convenient wrapper
        $t = Test::TAP::Model->new_with_tests(glob("t/*.t"));
        
        # that's shorthand for new->run_tests
        $t->run_tests(qw{ t/foo.t t/bar.t });

        # every file is an object (Test::TAP::Model::File)
        my @tests = $t->test_files;

        # this method returns a structure
        my $structure = $t->structure;

        # which is guaranteed to survive serialization
        my $other_struct = do { my $VAR; eval Data::Dumper::Dumper($structure) };

        # the same as $t1
        my $t2 = Test::TAP::Model->new_with_struct($other_struct);

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.

Well, you can use it to send test results, and process them into pretty reports. See Test::TAP::HTMLMatrix.

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.

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.

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:

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.

new
Creates an empty harness.
new_with_struct $struct
Adopts a structure. This is how you take a thawed structure and query it.
new_with_tests @tests
Takes a list of tests and immediately runs them.
get_tests
A method invoked by "run" 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 "get_tests".
run_tests @tests
Runs these tests. Just loops, and calls analyze file, with an eval { } around it to catch bail out.
run_test $test
Actually this is the part which does eval and calls "start_file" and "analyze_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 "test_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.

You can use any serializer you like (YAML, Storable, etc), to freeze "$obj->structure", and then you can thaw it back, and pass the thawed structure to "new_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.

Test::TAP::Model is a Test::Harness::Straps subclass. It knows to run tests on it's own. See the "run" methods and it's friends.

However, you should see how "run_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.

This module is maintained using Darcs. You can get the latest version from <http://nothingmuch.woobling.org/Test-TAP-Model/>, and use "darcs send" to commit changes.

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)
  • Audrey Tang <cpan@audreyt.org> AUDREYT
  • Gaal Yahas <gaal@forum2.org> GAAL

        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.
2008-06-22 perl v5.32.1

Search for    or go to Top of page |  Section 3 |  Main Index

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with ManDoc.