NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
bald-faced liar (Score:1)
Bald-faced means blatant, undisguised
Re: (Score:2)
I know what it means :) I just don't know why "bald-faced" is the term used.
Re: (Score:2)
The exit status case... (Score:1)
The obvious case for lack of exit status is PHP, where they are streaming TAP over HTTP and the HTTP stream will just stop at some point...
And anything else doing TAP over HTTP for that matter.
Re: (Score:2)
Wouldn't that just result in a 0 exit status, though? If we ignore a the exit status, we'd have to be doing that for a non-zero exit status, meaning that these don't matter.
Re: (Score:1)
Well, HTTP doesn't really HAVE an exit status to communicate, since it's SUPPOSED to be transactional... sort of.
The stream just stops, there's no return value as such.
BTW... (Score:1)
Pop quiz: is the following a failure? Why or why not? Is the existing behavior wrong?
1..3
ok 1 - Booting
ok 2 - Got dem boots!
ok 3 - We have foobar # TODO Waiting on foobar shipment
Asking if this is a fail is similar to asking if you run a test.
In the install context, this is a merely a curiosity. It's a difference in expected behaviour, and such for the author it's a fail(ure), but it's not a F
Re: (Score:2)
That's pretty much spot on, though I think the existing behavior might be wrong for authors. If you're an author, I would say that the "unexpectedly succeeded" should be a fail. Otherwise, it should not. We don't want heisenfails. I want to know if code I am developing is susceptible to this, but it shouldn't cause pain for anyone else. However, just like running tests in xt/, this is something the tester must explicitly request.