_indent() is a private method of Test::Builder

[schwern]

This is going to break in Test::Builder1.5.

Unfortunately, I don't have a better way to do it right now.

In addition, the Test::Builder structured diagnostic design is unlikely to follow the pattern of:

ok( ... );
structured_diagnostics( ... );

and instead do them either as a single call or building a single object. This is so that the result and diagnostics can be formatted as one. TAP is special in allowing them to be separate.

Sooo... I'm not sure what happens to this module in Test::Builder1.5 space. For the moment maybe detect a Test::Builder::VERSION >= 1.5 and die with a nice error message?

[renormalist]

There should be some way to indent, also in TB2. I was so happy to find that internal method
after years of doing it outside Test::Builder using lame regex filtering. I would happily switch the way
depending on TB version.

The ok+structured_diagnostics thing will probably not change soon, by the nature of TAP, as you said.
Although my TAP::DOM generates a parent/child connection on structured_diagnostics I'm aware that
the TAP creator has to take care of that relation in advance.

In our TAP-centric test infrastructure Tapper we always run "prove -m"
to at least merge STDERR into STDOUT to avoid divergence of ok and structured_diagnostics,
and in our non-Perl toolchains do not use STDERR at all for diagnostics, all just
to keep ok+structure_diagnostics together.

[renormalist]

Ah, and BTW, why not integrate the whole Test::TAPv13 functionality into TB2?

[schwern]

The real complication is this: Test::Builder 1.5 is no longer wielded to TAP. There's a multitude of different formatters now. Rather than test libraries crafting output directly, they send events which are used by the formatters to produce output. "Indent this output" or even "output this exactly" is not a concept that makes sense in Test::Builder 1.5, because a test library doesn't know what format the program has chosen (it could introspect and look, but don't do that).

Meta-data associated with a test result has been in the plans for some time, but Test::TAPv13's implementation doesn't make sense for Test::Builder 1.5. It would instead be additional data associated with Result, TestStart and TestEnd events. Potentially any event could have a hash of extra data attached to it.

I put this on hold because I need to concentrate on stabilizing Test::Builder 1.5, but you could work on it. Starting with something simple like is(). File and line information is already part of the result object and the "# Failed test" line is produced by the formatter from event information. Try changing TB2::Formatter::TAP::Base to produce structured diagnostics from a result. Try adding the have/want information to a result from is() and format that.

[exodist]

bump

With the release of Test2 this problem is once again surfacing. ->_indent is now gone, and this will not pass on the latest releases.

Here are some possible paths forward:

• Create Test2::Event::YAML using the Test2::Event structure (If you implement it correctly this can be a generic event that works regardless of formatter
• Create Test2::Formatter::TAPv13 which is a subclass of Test2::Formatter::TAP

I recommend doing both of these. You can write the YAML event and fire it off instead of doing what you do now. The TAPv13 formatter can output the TAP 13 header/pragma, and can write YAML output correctly according to spec. Using the generic interface the YAML can be rendered as comments, or hidden entirely in non-TAP13 formatters. Your module here could then simply provide the function to fire off YAML events, and also load/set the formatter.

[renormalist]

ACK. I will have a look.

Steffen

Chad Granum [email protected] writes:

bump

With the release of Test2 this problem is once again surfacing. ->_indent is now gone, and this will not pass on the latest releases.

Here are some possible paths forward:

• Create Test2::Event::YAML using the Test2::Event structure (If you implement it correctly this can be a generic event that works regardless of formatter
• Create Test2::Formatter::TAPv13 which is a subclass of Test2::Formatter::TAP

I recommend doing both of these. You can write the YAML event and fire it off instead of doing what you do now. The TAPv13 formatter can output the TAP 13 header/pragma, and can write YAML output
correctly according to spec. Using the generic interface the YAML can be rendered as comments, or hidden entirely in non-TAP13 formatters. Your module here could then simply provide the function to fire
off YAML events, and also load/set the formatter.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub*

Steffen Schwigon [email protected]

[renormalist]

I just marked this issue in RT as WONTFIX and uploaded a new version with a DEPRECATION hint in Changelog.
Not sure if I keep this ticket here open, too.