A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 15:00]:
>> I'm going to keep drilling through the BS until I either hit
>> bottom or punch through.
>
> Yeah, we’re all spouting bullshit. Gee, some tone you’re setting.
Sorry, I forgot the :)
That I'm pushing so hard to get something concrete out of you means I think
you've got something useful to say. That I'm not getting it is frustrating.
Seems I've finally got it, thank you.
>> About all that's different when the plan is at the end is the
>> TAP reader doesn't know how many tests are coming until the end
>> of the test. Then it can't display the expected number of tests
>> while the test is running.
>
> Not only can’t it do anything display-wise, but the harness also
> can’t do anything else that requires knowing the projected plan
> up front. It can’t abort the test as soon as the first extra test
> runs. If the test dies, the harness doesn’t know how many tests
> were pending. A system whose job is to continuously run lots of
> tests in parallel can’t do nearly as much useful asynchronous
> reporting.
>
>> Unfortunate, but hardly a showstopper.
>
> Whether or not it’s a showstopper is for the harness author
> to judge and not for you. It’s not hard to imagine cases where
> better streamability is important, even if they’re not garden-
> variety `./Build test` scenarios. We’re championing TAP as a
> solution for a wide variety of scenarios, right?
That's all things I haven't thought of. Since it doesn't effect the ultimate
quality of the tests, just some inconveniences in reporting, I'm not worried.
no_plan already has all these issues and the sky remains firmly fixed in the
heavens. Header-at-end TAP is still streamable. You don't have to read the
whole document before you can get information. It doesn't close off any
testing situations, and it makes quite a few more much simpler.
To make it clear, Test::Builder will still put the plan at front when it can.
Also, to make it clear, this is all possible right now with TAP. This is a
Test::Builder imposed restriction.
> But streamability isn’t important in that most common use case,
> so it probably shouldn’t be the default, which is why I opined
> that maybe Test::More should be strict on request but not by
> default.
Sorry, I must have missed that. Your example code up to this point looked
like it required the user to declare up front that they were going to put a
plan later.
Having the author declare in the test that they'd like Test::More to be strict
with the plan seems near useless. If you're going to declare that you have to
declare a plan, why not just declare the plan? It's like preparing to
prepare. I can think of a few weird cases where it might be handy, but it's
not worth the extra complication.
--
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer
