Skip to content
Novus Examples
tap251 B

TAP — Plan First, All Passing

The canonical TAP shape: a version line, a leading plan, then six passing assertions in order. Anything a TAP consumer does with a real stream it must do with this one first.

Preview — first 9 linestap
TAP version 13
1..6
ok 1 - cart applies the unit price
ok 2 - cart multiplies by quantity
ok 3 - cart rounds half up at two decimals
ok 4 - cart rejects a negative quantity
ok 5 - checkout creates a session
ok 6 - checkout restores the cart on resume

Specifications

Seed
61200
Encoding
UTF-8
Line Endings
LF
Tap Version
13
Plan Position
leading
Plan
1..6
Assertions
6
Ok
6
Not Ok
0
Skipped
0
Todo
0

Testing contract

Expected to pass
Scenario
Consume a well-formed TAP 13 stream and report the run as successful.
Expected result
6 assertions are read, all ok, and the count matches the declared plan 1..6.

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 — Plan First, All Passing” 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.

Generated by generation/testing.py. Free for any use, no attribution required — license.