chromatic wrote:
> On Friday 09 March 2007 14:50, Michael G Schwern wrote:
>
>> We can leverage any existing status system we want. HTTP status. Exit
>> status. Throw them all in! Don't find TAP's existing statuses rich
>> enough? Add your own extension keys! A particular status code not
On Friday 09 March 2007 14:50, Michael G Schwern wrote:
> We can leverage any existing status system we want. HTTP status. Exit
> status. Throw them all in! Don't find TAP's existing statuses rich
> enough? Add your own extension keys! A particular status code not make
> sense for your ap
Adam Kennedy wrote:
>> I propose that we prefix lines from STDERR with '! ' in the same way
>> that '# ' is used for diagnostics. wstat and exit can just be
>>
>> wstat 256
>> exit 1
>
> The problem with STDERR and exit is that we can't actually use them for
> anything significant.
>
> Otherwise
Andy Armstrong wrote:
> On 8 Mar 2007, at 22:47, Eric Hacker wrote:
>>> I propose that we prefix lines from STDERR with '! ' in the same way
>>> that '# ' is used for diagnostics. wstat and exit can just be
>>>
>>> wstat 256
>>> exit 1
>>
>> How about this?
>>
>> wstat: 256
>> exit: 1
>>
>> YAML,
On 3/8/07, Adam Kennedy <[EMAIL PROTECTED]> wrote:
Andy Armstrong wrote:
>> Otherwise when dealing with TAP streams that don't have a concept of
>> an exit code or a seperate error channel, the most common example
>> being web testing, we're left high and dry.
>
> In which case you'd just omit th
On 9 Mar 2007, at 01:44, Adam Kennedy wrote:
Like I said, we can't use them for anything that matters :)
It's just occurred to me that it makes it easier to write tests for
the harness too :)
I can't quite get my head round the objection to the idea that a TAP
transcript could be a comple
On 3/8/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
I propose that we prefix lines from STDERR with '! ' in the same way
that '# ' is used for diagnostics. wstat and exit can just be
wstat 256
exit 1
How about this?
wstat: 256
exit: 1
YAML, YAML, do!
;)
On 9 Mar 2007, at 00:28, Adam Kennedy wrote:
I propose that we prefix lines from STDERR with '! ' in the same
way that '# ' is used for diagnostics. wstat and exit can just be
wstat 256
exit 1
The problem with STDERR and exit is that we can't actually use them
for anything significant.
W
I propose that we prefix lines from STDERR with '! ' in the same way
that '# ' is used for diagnostics. wstat and exit can just be
wstat 256
exit 1
The problem with STDERR and exit is that we can't actually use them for
anything significant.
Otherwise when dealing with TAP streams that don
On 8 Mar 2007, at 22:47, Eric Hacker wrote:
I propose that we prefix lines from STDERR with '! ' in the same way
that '# ' is used for diagnostics. wstat and exit can just be
wstat 256
exit 1
How about this?
wstat: 256
exit: 1
YAML, YAML, do!
Doesn't look like TAP though :)
--
Andy A
On 8 Mar 2007, at 21:55, Michael G Schwern wrote:
Michael G Schwern wrote:
Stop. Stop stop stop! Stop right there.
Umm, people might not realize that I tend to be a bit over dramatic
and
didn't actually mean to shut down the discussion.
"He's not the Messiah. He's a very naughty boy". O
Michael G Schwern wrote:
> Stop. Stop stop stop! Stop right there.
Umm, people might not realize that I tend to be a bit over dramatic and
didn't actually mean to shut down the discussion.
Reading through this I can't help but thing I've seen it all before.
The PITA test result code conversation, if you'll recall.
But when that cloned something akin to HTTP codes it was because there
looked to be only 15-20 total possible results.
And it's not meant to be extensible the way TAP
On Mar 7, 2007, at 6:40 PM, Michael G Schwern wrote:
Repeat after me, "We cannot predict how TAP will be used".
That's why it's the "Test Anything Protocol". The A is Anything!
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Eric Hacker wrote:
I think this is a situation where you want a code rather than just
using text. The conciseness eases automatic interpretation and assures
clarity of what was said.
If so, then how many codes? Probably not as many as hundreds.
Best to group codes so that similar codes are easi
Gary Hawkins wrote:
2. Option to inject a clearcut delimiter between tests
Distinct from, say, outputting a diagnostic between groups of tests?
By 'tests' I'm thinking 'file' with its subtests, so-to-speak, so
yes,
anything that is clearly delineatable (LOL) programmatically where
one
'file
demerphq wrote:
If you want to say "Temporary Redirect" don't say "307" say "Temporary
Redirect"! If you want to put lots of information into one value, like
categorization, use a hash! { type => "Redirect", permanent => 0 }
Numeric response codes have the advantage that they are language agn
On Wednesday 07 March 2007 11:39, Eric Hacker wrote:
> Now if all TAP can handle is Perl, or even just code output, then
> those of us pushing the envelope will eventually migrate to some other
> test output format.
TAP can certainly handle more than just Perl and code output.
In my mind, the qu
On 3/7/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
It sounds as if you're doing monitoring rather than testing though.
Although they're related the requirements are quite different.
Poor explaining on my part then. Monitoring has similar needs, but us
usually much more shallow. Consider a we
On 3/7/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Any time you start writing a system that involves representing states as
numbers and doing bitmasks and math to add extra meaning, step back and
remind yourself that its 2007 and this is not C and you're not writing a
network protocol. You
How gross would it be just to have a logical channel in TAP that
could represent output to STDERR? That plus the exit status of the
test script is pretty much all you have at the moment. Would that be
so bad?
Perhaps, for non-Unix testing, perhaps not.
Here is what I have. There are bots that a
On 7 Mar 2007, at 21:24, Gary Hawkins wrote:
Not if verbose output.
Surely you jest. It is not reliably parsable, there can be garbage
text
on the end of those summary lines at times.
[snip]
If you want /parsed/ test results you'll be able to use TAPx::Parser
and/or TAPx::Harness to get
On 7 Mar 2007, at 21:15, Eric Hacker wrote:
Monitoring would check that the http server is up, and check that the
database server is up, but this is functional testing. Does the
application work, end to end.
OK, /now/ I understand.
That's what Test::More does. Otherwise, everything would just
2. Option to inject a clearcut delimiter between tests
>>>
>>> Distinct from, say, outputting a diagnostic between groups of tests?
>>
>> By 'tests' I'm thinking 'file' with its subtests, so-to-speak, so
yes,
>> anything that is clearly delineatable (LOL) programmatically where
one
>> 'file' o
On 7 Mar 2007, at 20:35, Gary Hawkins wrote:
2. Option to inject a clearcut delimiter between tests
Distinct from, say, outputting a diagnostic between groups of tests?
By 'tests' I'm thinking 'file' with its subtests, so-to-speak, so yes,
anything that is clearly delineatable (LOL) program
> > 2. Option to inject a clearcut delimiter between tests
> Distinct from, say, outputting a diagnostic between groups of tests?
By 'tests' I'm thinking 'file' with its subtests, so-to-speak, so yes,
anything that is clearly delineatable (LOL) programmatically where one
'file' output stops and a
On 7 Mar 2007, at 19:50, Gary Hawkins wrote:
1. Access to both STDERR and STDOUT, in proper order ('prove'
jumbles them), capturable into a variable (T::B snatches away STDERR)
TAP's a line oriented protocol so I imagine the best we can do is to
keep /lines/ from STDERR and STDOUT in the rig
On 3/7/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Mar 2007, at 13:48, Eric Hacker wrote:
> I think it was Ovid who recently called it the Test Anything Protocol.
> If really what is desired, then some additional complexity is
> required.
Sure - I'm completely in favour of being able to t
On 7 Mar 2007, at 19:39, Eric Hacker wrote:
Now, I know you are thinking about exit status on test scripts and I'm
thinking individual tests (of which running another test script might
be an instance), but in the distributed functional testing space, one
really can't rely on independent test scri
> OK, well we can talk about that now and at least get an idea of what
> kind of future we're proofing ourselves against. What do people
> envisage that we might want / be able to capture about a test run?
1. Access to both STDERR and STDOUT, in proper order ('prove' jumbles them),
capturable i
On 7 Mar 2007, at 19:21, demerphq wrote:
I guess it comes down to whether you can anticipate the possibility
that you will need new codes, and having a framework to put them into.
OK, well we can talk about that now and at least get an idea of what
kind of future we're proofing ourselves agai
On 3/7/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Mar 2007, at 18:59, demerphq wrote:
> Neither to me to be a very convincing reason to redesign something as
> well thought out as the HTTP response code schema. With it you have a
> well documented, well designed language agnostic response
On 7 Mar 2007, at 18:59, demerphq wrote:
Neither to me to be a very convincing reason to redesign something as
well thought out as the HTTP response code schema. With it you have a
well documented, well designed language agnostic response structure.
It seems to me youd have to work hard to come u
On 3/7/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Mar 2007, at 18:18, demerphq wrote:
>> If you want to say "Temporary Redirect" don't say "307" say
>> "Temporary
>> Redirect"! If you want to put lots of information into one value,
>> like
>> categorization, use a hash! { type => "Redir
On 7 Mar 2007, at 18:18, demerphq wrote:
If you want to say "Temporary Redirect" don't say "307" say
"Temporary
Redirect"! If you want to put lots of information into one value,
like
categorization, use a hash! { type => "Redirect", permanent => 0 }
Numeric response codes have the advanta
On 3/7/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Andy Armstrong wrote:
> On 7 Mar 2007, at 16:26, Eric Hacker wrote:
> [snip]
>> The first digit can be a grouping by success/failure.
>
> Yes, I see where you're going with this :)
>
>> So then if I'm not too far off base with the above, the
Andy Armstrong wrote:
On 7 Mar 2007, at 16:26, Eric Hacker wrote:
[snip]
The first digit can be a grouping by success/failure.
Yes, I see where you're going with this :)
So then if I'm not too far off base with the above, then to use
something different than HTTP::Status type codes would be
On 7 Mar 2007, at 16:26, Eric Hacker wrote:
[snip]
The first digit can be a grouping by success/failure.
Yes, I see where you're going with this :)
So then if I'm not too far off base with the above, then to use
something different than HTTP::Status type codes would be reinventing.
1xx Info
On 3/7/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Mar 2007, at 13:01, Eric Hacker wrote:
> Exit code or Status code?
Well let's generalise it and discuss the specifics: "any useful
information that's available when the test script terminates"
Ok
> The RFC Status codes might not be a
On 3/7/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
Ovid's post about TAP::Tests has reminded me: would it be useful to
have a TAP statement that conveys the exit code of a test script? At
the moment in a hypothetical situation where there's some distance
between the harness and the test script
On 7 Mar 2007, at 13:48, Eric Hacker wrote:
I think it was Ovid who recently called it the Test Anything Protocol.
If really what is desired, then some additional complexity is
required.
Sure - I'm completely in favour of being able to test anything and
capture everything that might be useful
On 7 Mar 2007, at 13:01, Eric Hacker wrote:
Exit code or Status code?
Well let's generalise it and discuss the specifics: "any useful
information that's available when the test script terminates"
The RFC Status codes might not be a perfect fit for test status, but
like the SIP protocol, th
Ovid's post about TAP::Tests has reminded me: would it be useful to
have a TAP statement that conveys the exit code of a test script? At
the moment in a hypothetical situation where there's some distance
between the harness and the test script - like perhaps they're on
different machines -
43 matches
Mail list logo
