Test Anything Protocol

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Test Anything Protocol" – news · newspapers · books · scholar · JSTOR (October 2017) (Learn how and when to remove this message)

The Test Anything Protocol (TAP) is a protocol for communicating between test logic, called a TAP producer, and a test harness in a language-agnostic way. Originally developed for unit testing of the Perl interpreter in 1987, producers and parsers are now available for many development platforms.

TAP was created for the first version of the Perl programming language (released in 1987), as part of the Perl's core test harness (t/TEST). The Test::Harness module was written by Tim Bunce and Andreas König to allow Perl module authors to take advantage of TAP. It became the de facto standard for Perl testing.^[1][2][3]

Development of TAP, including standardization of the protocol, writing of test producers and consumers, and evangelizing the language is coordinated at the TestAnything website.^[4]

As a protocol which is agnostic of programming language, TAP unit testing libraries expanded beyond their Perl roots and have been developed for various languages and systems such as PostgreSQL,^[5] MySQL,^[6] JavaScript^[7] and other implementations listed on the project site.^[4] A TAP C library is included as part of the FreeBSD Unix distribution and is used in the system's regression test suite.^[8]

A formal specification for this protocol exists in the TAP::Spec::Parser and TAP::Parser::Grammar modules. The behavior of the Test::Harness module is the de facto TAP standard implementation, along with a writeup of the specification on https://testanything.org.

A project to produce an IETF standard for TAP was initiated in August 2008, at YAPC::Europe 2008.^[4]

Here's an example of TAP's general format:

1..48 ok 1 Description # Directive # Diagnostic .... ok 47 Description ok 48 Description 

For example, a test file's output might look like:

1..4 ok 1 - Input file opened not ok 2 - First line of the input valid.     More output from test 2. There can be     arbitrary number of lines for any output     so long as there is at least some kind     of whitespace at beginning of line. ok 3 - Read the rest of the file #TAP meta information not ok 4 - Summarized correctly # TODO: not written yet 

• xUnit – Class of similar unit testing frameworks

• Site dedicated to the discussion, development and promotion of TAP