The Contributor Guidelines mention quoting all variables. I'm not sure if I should do this, or remain consistent with the existing code's usage of _flags variables...

YAML blocks are a feature of the TAP 13 specification. As a result, "TAP version 13" should be the first line a TAP producer writes to be spec-compliant. This allows TAP consumers such a python's tap.py to process YAML blocks. I'll update the PR accordingly.

Related with #49 right?

@BraisGabin, yes, this is related to #49. This adds duration when outputting test results in the TAP format, but not the regular format. A YAML document was chosen because some TAP consumers, such as Jenkins with it's TAP plugin, look for duration in this structured manner to display it in a CI system. I think diagnostic information, in my experience, is more useful in the TAP format to show a backtrace when a test failed.

Is there a way this might be useful when outputting in the default, non-TAP format? Not sure if there is a way that it could be done for automated tools to parse easily.

Looks like I need to rebase. I'll work on doing this.

+1, would like to use this. @gtkramer, what's the status?

would like to use it . Can anyone merge this PR?

Hi @gtkramer, sorry this has been open so long.

Could you rebase master onto this branch to resolve the conflicts please?

I wonder about optional Tap 13 syntax. Perhaps we should migrate entirely to Tap 13 instead of just for one flag's output? WDYT @mbland @jasonkarns?

Looking forward to use this function. Could someone please help to review and merge it?

@yahliu due to the time elapsed since submission (apologies!) these changes conflict with master and need rebasing to be merged.

If somebody is able to do that work we can get this merged. Feel free to discus here first, at first glance:

• there are now multple output formats that each require this patched in
• tests for each format
• I'm not sure if this will conflict with other work on traps recently

@sublimino I see latest code already have the time option -T, --timing, but it didn't shown in the Jenkins TAP plugin.

Based on my checking, the TAP plugin will get keywords duration_ms, but -T, --timing have no such it. so I think it's better to enhance -T, --timing to support it.

I am looking into getting this to fly with the current codebase. My observations:

1. the current option measures in full seconds, this one uses milliseconds
2. I see big problems with maintaining both TAP and TAP 13 output in parallel, as @sublimino already said it would probably be benificial to go full TAP 13 then. However, this would require large redesigns of the test suite which relies on the old TAP format
3. using TAP 13 internally would require a yaml parser or some very strict formatting to apply formatters

My proposal would be:

1. update the timing code to use millisecond precision
2. Add a TAP13 formatter for consumption by Jenkins TAP, this could even be an external project

I am closing this since #337 has been merged.