TAP — Failures with YAML Diagnostics
Two failing assertions, each followed by an indented YAML diagnostic block carrying the expected and actual values and a file/line location. The block is where every useful failure message in TAP lives, and it is the part naive line-based parsers throw away.
TAP version 13
1..4
ok 1 - cart applies the unit price
not ok 2 - cart applies tax to the subtotal
---
message: 'expected 12.60, got 12.59'
severity: fail
data:
got: 12.59
expect: 12.6
at:
file: test/pricing.test.js
line: 88
column: 7
...
ok 3 - cart rounds half up at two decimals
not ok 4 - cart rejects a negative quantity
---
message: 'expected the call to throw'
severity: fail
...
Specifications
- Seed
- 61200
- Encoding
- UTF-8
- Line Endings
- LF
- Tap Version
- 13
- Plan Position
- leading
- Plan
- 1..4
- Assertions
- 4
- Ok
- 2
- Not Ok
- 2
- Skipped
- 0
- Todo
- 0
- Yaml Diagnostic Blocks
- 2
Testing contract
Expected to pass- Scenario
- Extract structured failure detail from the YAML block attached to a not-ok line.
- Expected result
- Assertion 2 yields got=12.59, expect=12.6 and test/pricing.test.js line 88 from its diagnostic block.
What is a .tap file?
TAP (Test Anything Protocol) is a line-based plain-text format for reporting test results. A stream declares a plan such as `1..12` and then emits one `ok` or `not ok` line per test, optionally with a description, a `# SKIP` or `# TODO` directive, and an indented YAML block carrying diagnostic detail. It is deliberately simple enough that a test runner in any language can emit it and a harness can parse it line by line.
How to use this file
Use an example .tap file to test TAP consumers, CI result parsers, and format converters — checking that the declared plan matches the number of assertions, that skipped and TODO directives are classified separately from failures, and that diagnostic YAML blocks survive the round trip.
How to use this file for testing
“TAP — Failures with YAML Diagnostics” is a deterministic Novus Examples fixture for Log parsing, Error handling, Conversion testing. Access logs and JSON-lines application logs — for testing log parsers, tailers, and ingestion pipelines.
Documented properties for this file: seed 61200 · UTF-8 · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Test and coverage reports document their totals (suites, cases, passes, failures, skips, covered lines) in the spec table. Point your CI dashboard, coverage gate, or report converter at the file and assert those counts survive; format twins carry identical numbers so a conversion can be scored exactly.
Related files
- tapTAP — Entire Plan SkippedA whole suite declined in a single line: a zero-length plan with a SKIP directive and a reason. It is a valid, complete TAP stream containing no assertions, and a consumer must report it as skipped rather than as an empty pass or a parse error.
- tapTAP — Nested Subtests (Indented)Two subtests, each an indented TAP stream with its own plan, rolled up into two top-level assertions. Flatten it and you count seven assertions instead of two; ignore the indentation and the nested failure is counted twice.
- tapTAP — SKIP DirectivesTwo assertions marked # SKIP with a reason, alongside a genuine failure. Skipped assertions are written as ok, so counting ok lines reports 5 passes when only 3 tests actually ran.
- tapTAP — TODO DirectivesTwo failing assertions marked # TODO, meaning they are known-unfinished work rather than regressions. A TODO failure must not fail the run, so a consumer that treats every not ok as a build breaker turns this green run red.
- tapTAP — TODO That Unexpectedly PassedAssertion 2 is marked TODO but reports ok — an unexpected success, which means the feature landed and the marker is now stale. Harnesses such as prove report this as a bonus rather than a pass, and dropping the distinction lets stale TODOs accumulate forever.
- tapTAP — Version 14 Subtest SyntaxTAP 14 with an explicit version line and a pragma inside a subtest. Consumers pinned to version 13 either reject the stream outright or ignore the pragma, so this file separates the two behaviours.
Generated by generation/testing.py. Free for any use, no attribution required — license.