Specification
Specification copied to clipboard
TestAnything
Working towards a new TAP specification
First of all - thanks for your work with updating specification! One of the goals of TAP14 is: > Document the observed behavior of widely used TAP implementations. I believe...
TAP13 is a simple and well-known format for testing results. TAP14 is based on TAP13 format with a number if innovations. I believe it would be helpful for readers to...
Is this sentence correct? > TAP, the Test Anything Protocol, is a simple text-based interface between testing modules a test harness.
The current [spec](https://testanything.org/tap-version-13-specification.html) describes a case for reporting messages via the YAML format: ``` TAP version 13 1..N ok 1 Description # Directive # Diagnostic --- message: 'Failure message' severity:...
This issue was originally reported in https://github.com/TestAnything/testanything.github.io/issues/20, and the conversation has been moved here since it is related to the TAP specification. It concerns the subtests in TAP and a...
Right now tap assumes that unknown messages are diagnostics for the preceding "ok"/"not ok" line. In some cases it would be very nice and natural to reverse this. It also...
In order to support concurrency, I suggest we drop the requirement that tests appear in order. As long as all test numbers between 1 and the plan are encountered, and...
For TAP to grow, I think we need to not break existing implementations. Here's my proposal: - Every feature request must be submitted as a pull request and have an...
It'd be nice to have a standard way to pass test duration (ie, the amount of time it took for a test to complete), as well as the total time...
The new TAP should have explicit concurrency support, that is where TAP can be generated via multiple threads. Note: For most things there is no guarantee of atomic writes, but...