Hiya,

On 29 Oct 2011, at 10:20, Michael G Schwern wrote:

> On 2011.10.29 1:51 AM, Adrian Howard wrote:
>> On 29 Oct 2011, at 09:18, Michael G Schwern <schw...@pobox.com> wrote:
>> [snip]
>>> Do you find *blocks with their own name and plan* convenient, or subtests
>>> which have their own separate test state (as currently implemented)
>> 
>> This may be me being dim - but I'm not really groking the distinction you're
>> making. Could you give an example of the kind of difference that you're
> proposing?
> 
> It's *mostly* internal, but here's an example to explain the difference.
> 
> Here's how subtests currently work:
[snip]
>    ok 1 - First test
>        1..2
>        ok 1 - This is a subtest
>        ok 2 - So is this
>    ok 2 - An example subtest
>    ok 3 - Third test
>    1..3
[snip]
> What I'm asking would it make much difference to how subtests are used if it 
> was like this:
> 
>    This would produce.
> 
>    ok 1 - First test
>    # An example of a subtest
>    ok 2 - This is a subtest
>    ok 3 - So is this
>    ok 4 - Last test
>    1..4
[snip]

Thanks - understand now. 

I prefer the current subtests system for a few reasons:

* With the new system I would have to re-write TAP streams from other sources 
to match the numbering system of the current stream. This makes more work for 
folk who are pulling in TAP streams from other boxes/processes. If we do go 
this route you would, ideally, need to have a "standard" system for 
renumbering/counting streams.

* I cannot, in a general way, tell the difference between a TAP stream with 
subtests and a linear TAP stream. This means I can do things like easily report 
whether certain levels of subtests are passing/failing.  I'm using nesting 
because the groups make logical sense. Throwing that information away in the 
TAP output seems a bad thing to me - it's useful to analyse/view the results as 
well as organising the tests.

* With no "standard" way of representing the nesting in the TAP stream output - 
everybody who needs to manage any kind of test grouping / hierarchy has to 
invent their own way of doing it.

* Test::Block kinda uses this system. Never really used by anybody. subtests 
are already used by lots of folk. I think part of the reason why may be coz of 
the more intention revealing output?

* How would a no_plan subtest merge into a planned stream?

... and probably some more if I carry on thinking about it. But that's enough 
for now ;-)

Cheers,

Adrian
-- 
http://quietstars.com     adri...@quietstars.com     twitter.com/adrianh    
t. +44 (0)7752 419080     skype adrianjohnhoward     del.icio.us/adrianh

Reply via email to