TAP::DOM - TAP as Document Object Model.
# Create a DOM from TAP use TAP::DOM; my $tapdom = TAP::DOM->new( tap => $tap ); # same options as TAP::Parser print Dumper($tapdom); # Recreate TAP from DOM my $tap2 = $tapdom->to_tap;
The purpose of this module is
That is useful when you want to analyze the TAP in detail with "data exploration tools", like Data::DPath.
``Reliable'' means that this structure is kind of an API that will not change, so your data tools can, well, rely on it.
Constructor which immediately triggers parsing the TAP via TAP::Parser and returns a big data structure containing the extracted results.
my $tap; { local $/; open (TAP, '<', 't/some_tap.txt') or die; $tap = <TAP>; close TAP; } my $tapdata = TAP::DOM->new ( tap => $tap disable_global_kv_data => 1, put_dangling_kv_data_under_lazy_plan => 1, ignorelines => '(## |# Test-mymeta_)', dontignorelines => '# Test-mymeta_(tool1|tool2)_', preprocess_ignorelines => 1, preprocess_tap => 1, usebitsets => 0, ignore => ['as_string'], # keep 'raw' which is the unmodified variant document_data_prefix => '(MyApp|Test)-', lowercase_fieldnames => 1, trim_fieldvalues => 1, );
Arrayref of fieldnames not to contain in generated TAP::DOM. For example you can skip the as_string field which is often a redundant variant of raw.
as_string
raw
A regular expression describing lines to ignore.
Be careful to not screw up semantically relevant lines, like indented YAML data.
The regex is internally prepended with a start-of-line ^ anchor.
^
This is the whitelist of lines to not being skipped when using the ignore blacklist.
ignore
The dontignorelines feature is HIGHLY EXPERIMENTAL, in particular in combination with preprocess_ignorelines.
dontignorelines
preprocess_ignorelines
Background: the preprocessing is done in a single regex operation for speed reasons, and to do that the dontignorelines regex is turned into a zero-width negative-lookahead condition and prepended before the ignorelines condition into a combined regex.
ignorelines
Without preprocess_ignorelines it is a relatively harmless additional condition during TAP line processing.
Survival tips:
have unit tests for your setup
do not use ^ anchors neither in ignorelines nor in dontignorelines but rely on the implicitly prepended anchors.
write both ignorelines and dontignorelines completely describing from beginning of line (yet without the ^ anchor).
do not use it but define ignorelines instead with your own zero-width negative-lookaround conditions
know the zero-width negative look-around conditions of your use Perl version
Instead of having a lot of long boolean fields like
has_skip => 1 has_todo => 0
you can encode all of them into a compact bitset
is_has => $SOME_NUMERIC_REPRESENTATION
This field must be evaluated later with bit-comparison operators.
Originally meant as memory-saving mechanism it turned out not to be worth the hazzle.
Early TAP::DOM versions put all lines like
# Test-foo: bar
into a global hash. Later these fields are placed as children under their parent ok/not ok line but kept globally for backwards compatibility. With this flag you can drop the redundant global hash.
ok
not ok
But see also put_dangling_kv_data_under_lazy_plan.
put_dangling_kv_data_under_lazy_plan
This addresses the situation what to do in case a key/value field from a line
appears without a parent ok/not ok line and the global kv_data hash is disabled. When this option is set it's placed under the plan as parent.
To interpret lines like
the document_data_prefix is by default set to Test- so that a key/value field
document_data_prefix
Test-
foo => 'bar'
is generated. However, you can have a regular expression to capture other or multiple different values as allowed prefixes.
This is another regex-based way to avoid generating particular fields. This regex is matched against the already extracted keys, and stops processing of this field for document_data and kv_data.
document_data
kv_data
If set to a true value all recognized fields are lowercased.
If set to a true value all recognized values are lowercased.
If set to a true value all field values are trimmed of trailing whitespace. Note that fields don't have leading whitespace as it's already consumed away after the fieldname separator colon :.
:
All other provided parameters are passed through to TAP::Parser, see sections "HOW TO STRIP DETAILS" and "USING BITSETS". Usually the options are just one of those:
tap => $some_tap_string
or
source => $test_file
But there are more, see TAP::Parser.
Called on a TAP::DOM object it returns a string that is TAP.
The data structure is basically a nested hash/array structure with keys named after the functions of TAP::Parser that you normally would use to extract results.
See the TAP example file in t/some_tap.txt and its corresponding result structure in t/some_tap.dom.
t/some_tap.txt
t/some_tap.dom
Here is a slightly commented and beautified excerpt of t/some_tap.dom. Due to it's beeing manually washed for readability there might be errors in it, so for final reference, dump a DOM by yourself.
bless( { # general TAP stats: 'version' => 13, 'plan' => '1..6', 'tests_planned' => 6 'tests_run' => 8, 'is_good_plan' => 0, 'has_problems' => 2, 'skip_all' => undef, 'parse_errors' => 1, 'parse_errors_msgs' => [ 'Bad plan. You planned 6 tests but ran 8.' ], 'pragmas' => [ 'strict' ], 'exit' => 0, 'start_time' => '1236463400.25151', 'end_time' => '1236463400.25468', # the used TAP::DOM specific options to TAP::DOM->new(): 'tapdom_config' => { 'ignorelines' => qr/(?-xism:^## )/, 'usebitsets' => undef, 'ignore' => {} }, # summary according to TAP::Parser::Aggregator: 'summary' => { 'status' => 'FAIL', 'total' => 8, 'passed' => 6, 'failed' => 2, 'all_passed' => 0, 'skipped' => 1, 'todo' => 4, 'todo_passed' => 2, 'parse_errors' => 1, 'has_errors' => 1, 'has_problems' => 1, 'exit' => 0, 'wait' => 0 'elapsed' => bless( [ 0, '0', 0, 0, 0, 0 ], 'Benchmark' ), 'elapsed_timestr' => ' 0 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU)', }, # all recognized TAP lines: 'lines' => [ { 'is_actual_ok' => 0, 'is_bailout' => 0, 'is_comment' => 0, 'is_plan' => 0, 'is_pragma' => 0, 'is_test' => 0, 'is_unknown' => 0, 'is_version' => 1, # <--- 'is_yaml' => 0, 'has_skip' => 0, 'has_todo' => 0, 'severity' => 0, 'raw' => 'TAP version 13' 'as_string' => 'TAP version 13', }, { 'is_actual_ok' => 0, 'is_bailout' => 0, 'is_comment' => 0, 'is_plan' => 1, # <--- 'is_pragma' => 0, 'is_test' => 0, 'is_unknown' => 0, 'is_version' => 0, 'is_yaml' => 0, 'has_skip' => 0, 'has_todo' => 0, 'severity' => 0, 'raw' => '1..6' 'as_string' => '1..6', }, { 'is_actual_ok' => 0, 'is_bailout' => 0, 'is_comment' => 0, 'is_ok' => 1, # <--- 'is_plan' => 0, 'is_pragma' => 0, 'is_test' => 1, # <--- 'is_unknown' => 0, 'is_unplanned' => 0, 'is_version' => 0, 'is_yaml' => 0, 'has_skip' => 0, 'has_todo' => 0, 'number' => '1', # <--- 'severity' => 1, 'type' => 'test', 'raw' => 'ok 1 - use Data::DPath;' 'as_string' => 'ok 1 - use Data::DPath;', 'description' => '- use Data::DPath;', 'directive' => '', 'explanation' => '', '_children' => [ # ----- children are the subsequent comment/yaml lines ----- { 'is_actual_ok' => 0, 'is_unknown' => 0, 'has_todo' => 0, 'is_bailout' => 0, 'is_pragma' => 0, 'is_version' => 0, 'is_comment' => 0, 'has_skip' => 0, 'is_test' => 0, 'is_yaml' => 1, # <--- 'is_plan' => 0, 'raw' => ' --- - name: \'Hash one\' value: 1 - name: \'Hash two\' value: 2 ...' 'as_string' => ' --- - name: \'Hash one\' value: 1 - name: \'Hash two\' value: 2 ...', 'data' => [ { 'value' => '1', 'name' => 'Hash one' }, { 'value' => '2', 'name' => 'Hash two' } ], } ], }, { 'is_actual_ok' => 0, 'is_bailout' => 0, 'is_comment' => 0, 'is_ok' => 1, # <--- 'is_plan' => 0, 'is_pragma' => 0, 'is_test' => 1, # <--- 'is_unknown' => 0, 'is_unplanned' => 0, 'is_version' => 0, 'is_yaml' => 0, 'has_skip' => 0, 'has_todo' => 0, 'explanation' => '', 'number' => '2', # <--- 'type' => 'test', 'description' => '- KEYs + PARENT', 'directive' => '', 'severity' => 1, 'raw' => 'ok 2 - KEYs + PARENT' 'as_string' => 'ok 2 - KEYs + PARENT', }, # etc., see the rest in t/some_tap.dom ... ], }, 'TAP::DOM') # blessed
As you can see above, diagnostic lines (comment or yaml) are nested into the line before under a key _children which simply contains an array of those comment/yaml line elements.
_children
With this you can recognize where the diagnostic lines semantically belong.
You can make the DOM a bit more terse (i.e., less blown up) if you do not need every detail.
For this provide the ignore option to new(). It is an array ref specifying keys that should not be contained in the TAP-DOM. Currently supported are:
has_todo has_skip directive as_string explanation description is_unplanned is_actual_ok is_bailout is_unknown is_version is_bailout is_comment is_pragma is_plan is_test is_yaml is_ok number type raw
Use it like this:
$tapdom = TAP::DOM->new (tap => $tap, ignore => [ qw( raw as_string ) ], );
You can ignore complete lines from the input TAP as if they weren't existing by by setting a regular expression in ignorelines. Of course you can break the TAP with this, so usually you only apply this to non-TAP lines or diagnostics you are not interested in.
My primary use-case is TAP with large parts of logfiles included with a prefixed "## " just for dual-using the TAP also as an archive of the log. When evaluating the TAP later I leave those log lines out because they only blow up the memory for the TAP-DOM:
$tapdom = TAP::DOM->new (tap => $tap, ignorelines => qr/^## /, );
See t/some_tap_ignore_lines.t for an example.
t/some_tap_ignore_lines.t
WARNING, experimental features!
By setting that option, ignorelines is applied to the input TAP text before it is parsed.
This could help to speed up TAP parsing when there is a huge amount of non-TAP lines that the regex engine could throw away faster than TAP::Parser would parse it line by line.
There is a risk: without that option, only lines are filtered that are already parsed as lines by the TAP parser. If applied before parsing, the regex could mis-match non-trivial situations.
preprocess_tap
With this option, any lines that don't obviously look like TAP are stripped away.
There is a substantial risk, though: the purely line-based regex processing could screw up when it mis-matches lines. Parsing TAP is not as obvious as it seems first. Just think of unindented YAML or indented YAML with strange multi-line spanning values at line starts, or the (non-standardized and unsupported) nested indented TAP. So be careful!
noempty_tap
When a document is empty (which can also happen after preprocessing) then this option set to 1 triggers to put in some replacement line.
pragma +tapdom_error # document was empty
which in turn assigns it an error severity, so that these situations are no longer invisible.
You can make the DOM even smaller by using the option usebitsets:
usebitsets
$tapdom = TAP::DOM->new (tap => $tap, usebitsets => 1 );
In this case all the 'has_*' and 'is_*' attributes are stored in a common bitset entry 'is_has' with their respective bits set.
This reduces the memory footprint of a TAP::DOM remarkably (for large TAP-DOMs ~40%) and is meant as an optimization option for memory constrained problems.
You can get the actual values of 'is_*' and 'has_*' attributes regardless of their storage as hash entries or bitsets by using the respective methods on single entries:
if ($tapdom->{lines}[4]->is_test) {...} if ($tapdom->{lines}[4]->is_ok) {...} ...
or with even less direct hash access
if ($tapdom->lines->[4]->is_test) {...} if ($tapdom->lines->[4]->is_ok) {...} ...
You can also use constants that represent the respective bits in expressions like this:
if ($tapdom->{lines}[4]{is_has} | $TAP::DOM::IS_TEST) {...}
And the constants can be imported into your namespace:
use TAP::DOM ':constants'; if ($tapdom->{lines}[4]{is_has} | $IS_TEST ) {...}
By setting option lowercase_fieldnames all field names (hash keys) in document_data and kv_data are set to lowercase. This is especially helpful to normalize different casing like
lowercase_fieldnames
# Test-Strange-Key: some value # Test-strange-key: some value # Test-STRANGE-KEY: some value
etc. all into
"strange-key" => "some value"
By setting option lowercase_fieldvalues all field values in document_data and kv_data are set to lowercase. This is especially helpful to normalize different casing like
lowercase_fieldvalues
# Test-strange-key: Some Value # Test-strange-key: Some value # Test-strange-key: SOME VALUE
Warning: while the sister option lowercase_fieldnames above is obviously helpful to keep the information more together, this lowercase_fieldvalues option here should be used with care. You loose much more information here which is usually better searched via case-insensitive options of the mechanism you use, regular expressions, Elasticsearch, etc.
Normally a key:value pair {foo = bar}> from a line like
{foo =
ends up as entry in a has kv_values under the entry before that line - which ideally is either a normal ok/not_ok line or a plan line.
kv_values
If that's not the case then it is not clear where they belong. Early TAP::DOM versions had put them under a global entry document_data.
However this makes these entries inconsistently appear in different levels of the DOM. so you can suppress that old behaviour by setting disable_global_kv_data to 1.
disable_global_kv_data
However, with that option now, there can be lines that appear directly at the start with no preceding parent line, in case the plan comes at the end of the document. To not loose those key values they can be saved up until the plan appears later and put it there. As this reorders data inside the DOM differently from the original document you must explicitely request that behaviour by setting put_dangling_kv_data_under_lazy_plan to 1.
Summary: for consistency it is suggested to set both options:
disable_global_kv_data => 1, put_dangling_kv_data_under_lazy_plan => 1
A document can contain comment lines which actually contain key/value data, like this:
# Test-vendor-id: GenuineIntel # Test-cpu-model: Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz # Test-cpu-family: 6 # Test-flags.fpu: 1
Those lines are converted into a hash by splitting it at the : delimiter and stripping the # Test- prefix. The resulting data structure looks like this:
# Test-
# ... inside TAP::DOM ... document_data => { 'vendor-id' => 'GenuineIntel', 'cpu-model' => #Intel(R) Core(TM) i7-3667U CPU @ 2.00GHz', 'cpu-family' => 6, 'flags.fpu' => 1, },
TAP::DOM creates attributes beyond those from TAP::Parser, usually to simplify later processing.
The severity describes the combination of ok/not ok and todo/skip directives as one single numeric value.
severity
todo
skip
This allows to handle the otherwise nominal values as ordinal value, i.e., it provides them with a particular order.
This order is explained as this:
0 - represents the 'missing' severity.
It is used for all things that are not a test or as fallback when the other attributes appear in illegal combinations (like saying both SKIP and TODO).
1 - straight ok.
2 - ok with a #TODO
#TODO
That's slightly worse than a straight ok because of the directive.
3 - ok with a #SKIP
#SKIP
That's one step worse because the ok is not from actual test execution, as that's what skip means.
4 - not_ok with a #TODO
That's worse as it represents a fail but it's a known issue.
5 - straight not_ok.
A straight fail is the worst real-world value.
6 - forbidden combination of a not_ok with a #SKIP.
How can it fail when it was skipped? That's why it's even worse than worst.
A severity value is set for lines of type test and plan.
test
plan
Additionally, it is set on the TAP::DOM-specific pragma +tapdom_error with a severity value 5 (i.e., not_ok). Because a pragma doesn't interfere with test/plan lines you can use this to express an out-of-band error situation which would be lost otherwise. Read below for more.
+tapdom_error
Pragmas in TAP are meant to influence the behaviour of the TAP parser.
TAP::DOM recognizes special pragmas. They are all prefixed with tapdom_.
tapdom_
So far there is:
+tapdom_error - assign this line a severity of 5 (not ok)
You can for instance append this pragma to the TAP document during post-processing to express an out-of-band error situation without interfering with the existing test lines and plan.
Typical situations can be a an error from prove or other TAP processor, and you want to ensure this problem does not get lost when storing the document in a database.
prove
Pragmas allow kv_data like in test and plan lines, so you can transport additional error details like this:
pragma +tapdom_error # Test-tapdom-error-type: prove # Test-tapdom-prove-exit: 1
Steffen Schwigon <ss5@renormalist.net>
This software is copyright (c) 2023 by Steffen Schwigon.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.
To install TAP::DOM, copy and paste the appropriate command in to your terminal.
cpanm
cpanm TAP::DOM
CPAN shell
perl -MCPAN -e shell install TAP::DOM
For more information on module installation, please visit the detailed CPAN module installation guide.