Front page | perl.qa |
Postings from October 2011
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 <schwern@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 adrianh@quietstars.com twitter.com/adrianh t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianhThread Previous | Thread Next