[tap-l] Nested TAP

Andy Armstrong andy at hexten.net
Tue Apr 15 20:17:40 UTC 2008


On 15 Apr 2008, at 02:44, Aristotle Pagaltzis wrote:
> In fact, we should probably make v13 allow both the presence and
> absence of the back-compat shim line. That way, people can write
> v13 producers now that work with v12 consumers now, but those who
> have upgraded their entire infrastructure can shed that crutch.

I think that's a good compromise. So we'd have begin and end, tests  
inside the begin/end block optionally indented and an optional summary  
result after the end with the same number as the preceding nested  
block. That allows for

     1..3
     ok 1
     begin 2
     1..2
     not ok 1
     ok 2
     end 2
     ok 3

and

     1..3
     ok 1
     begin 2
         1..2
         not ok 1
         ok 2
     end 2
     ok 3

and

     1..3
     ok 1
     begin 2
         1..2
         not ok 1
         ok 2
     end 2
     not ok 2
     ok 3

All are valid TAP v13. The third version is also compatible with v12  
and earlier.

I think the semantics for the summary assertion should work like this:

===

After a numbered nested TAP block a TAP producer may optionally emit a  
"summary result" with the same number as the block. The overall  
success of the block is (success of nested TAP AND success of summary  
result). A summary result can therefore cause an otherwise apparently  
successful nested block to fail.

===

And in fact that's quite tidy because we can say that a result is  
either a block, a simple result or both in which case the simple  
result must follow the block.

A small point - that gives us no less than three sites where YAML  
diagnostics scoped for the entire nested block can be situated

     1..3
     ok 1
     begin 2
         TAP version 13
         ---
         yaml: 'here'
         ...
         1..2
         not ok 1
         ok 2
     end 2
     ---
     or: 'here'
     ...
     not ok 2
     ---
     or: 'even here'
     ...
     ok 3

The first of those three is probably not a problem. I guess the parser  
will have an API that treats the interior of the block as a self  
contained TAP document via which the YAML diagnostic can be reached.  
The other two are resolved either by saying they can both appear or by  
ruling that only the third location is valid I think. I vote for the  
latter.

-- 
Andy Armstrong, Hexten



More information about the tap-l mailing list