Re: [tap] RFC Status?

Andrew de Andrade <> Mon, 11 August 2014 21:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 651E11A00BE for <>; Mon, 11 Aug 2014 14:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2a2U5ioJlMQp for <>; Mon, 11 Aug 2014 14:31:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8F341A006C for <>; Mon, 11 Aug 2014 14:31:17 -0700 (PDT)
Received: by with SMTP id j7so8438228qaq.28 for <>; Mon, 11 Aug 2014 14:31:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1+5YzKLBUZe9YU+PmvKWizZlh03RHd0lAMZDeeZf8v4=; b=jrZtzkXGGXaWk0UTuzZr3Quh+q88g3Hj0L+YnByDJ++azuX9QIA33tKn0nAY3oyFx/ 9tKVkOrXB3C2l5XHkQhCe318bl4yjtCoj/bPM2AeGV7xA+IIN+qGf0YBP5URGeESuqd+ iJ20SQGXLvWF5P55Yv7vq+FlbGSfJ4cFLxQSBFqGKh3Al1+T+8z0O63X4YPmKux57rpw PzzxJwn1pi5Xz/TEdZOnqBR+UvkVWn9hhuVUY0Vky5qu5jT7EQlAMmdCqvIKsA2MxgTO UmZFxi0J2vqyzGBOw1ntrXLSG1WcsPj/MusJLWhtskj01kZwZQu2cocr2OTshmo8dFy6 A2OQ==
X-Gm-Message-State: ALoCoQnjSiKyrh0UaT7syqNGDM4PiR9InfAuq8avoz8l8Mfp80okom+RA9YXBdlGAbfsVG/6Tt4p
X-Received: by with SMTP id j8mr662829qaa.8.1407792676806; Mon, 11 Aug 2014 14:31:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 11 Aug 2014 14:30:56 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <>
From: Andrew de Andrade <>
Date: Mon, 11 Aug 2014 14:30:56 -0700
Message-ID: <>
To: "Bruno P. Kinoshita" <>
Content-Type: multipart/alternative; boundary=047d7bea31846ba1200500614661
Cc: "" <>
Subject: Re: [tap] RFC Status?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Test Anything Protocol WG discussions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Aug 2014 21:31:20 -0000

Yes, this all helps a bunch. I've been using substack's tape ( and isaacs' tap ( modules thus far.

tape currently supports v13, which as you pointed out Bruno, does not
formally specify how nesting should work, and it does support defining
tests in a nested way, but does not report them as nested. Instead, it
simply updates the plan count and continues with everything flat/unindented
and reports the plan count at the end. For example this code...

var test = require('tape');

test('foobar', function(t) {
  //var test = tape.createHarness();

  t.ok(true, 'foo');
  t.ok(true, 'bar');

  t.test('fibble', function(tt) {
    tt.ok(true, 'wobble');
    tt.ok(true, 'wizzle');

TAP version 13
# foobar
ok 1 foo
ok 2 bar
# fibble
ok 3 wobble
ok 4 wizzle

# tests 4
# pass  4

# ok

What I did just find is an implementation from Ovid from earlier this year
in March:

This stream approach is really nice, but the only thing that leaves me
scratching my head is that is implies that asynchrony is permitted
(parallelized tests, aggregation, out-of-order reporting), but I'm not
exactly sure what the implications for this are for the aggregate tap

Should the aggregate reporter report subtests as they are received or
should it keep the subtest results that finish out of order in a buffer and
always report the tests in a deterministic way? I did see this in the
readme, , implying AFAICT that
it is left up to the TAP aggregator consuming the stream to either report
things in order with or without numbers (if desired) or out of order, but

Given my intended use case, buffering results so that results can always be
reported numbered in order would be desirable, since I want to be able to
diff TAP results across test runs under different conditions (e.g.
different dependency versions). Has anyone done any work with diffing TAP

Bruno, is tap4j purely synchronous or at least in order or can subtests be
asynchronous and reported out of order?

Seeing that Ovid is still actively working on this stuff (comments on tap
on perlqa3 as recent as April this year), is it save to assume that there
are ideas here that will make it into version 14? The test blocks you
pointed to does reference version 14 in the example -->