Ricardo SIGNES wrote:
* brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26]
I'm not talking about the particular field name, but the idea that I'd
want to say in META.yml Don't send me mail, or whatever setting I
want.
Instead of having to disable (or enable) CC for every new tool, I'd
want a
Graham Barr wrote:
On Mar 5, 2007, at 1:56 PM, Eric Wilhelm wrote:
* brian d foy [EMAIL PROTECTED] [2007-03-04T12:09:26]
I'm not talking about the particular field name, but the idea that
I'd want to say in META.yml Don't send me mail, or whatever
setting I want.
Instead of having to
(Grr ... one day I'll remember to post from the correct email address)
This is me, beating this camel again, hoping that money might revive
it.
This discussion of no_plan work and fixing other testing functions
reminds me that creating a new testing module (TAP::Tests) would still
be useful. We
Ovid wrote:
Sounds like a replacement for Test::Builder not just Test::More.
Well, I guess it would be a replacement for Test::Builder and various
testing modules. It would be rather important to try and make it work
with existing test modules, though. Not sure how workable that would
be
Ovid wrote:
This would also be a nice development path for TAP 2.0.
Minor nit... please please please use integer version numbers. Please.
http://perl-qa.yi.org/index.php/TAP_version
On 7 Mar 2007, at 12:38, Michael G Schwern wrote:
Minor nit... please please please use integer version numbers.
Please.
http://perl-qa.yi.org/index.php/TAP_version
Indeed. It's not like we're going to run out of positive integers.
Schema versions should always be integers.
--
Andy
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,
On 3/7/07, Adrian Howard [EMAIL PROTECTED] wrote:
On 5 Mar 2007, at 22:30, Ovid wrote:
(Resent from the address I've actually subscribed from!)
Hi all,
Per an email from Schwern, he does not object to renaming TAPx::Parser
to TAP::Parser. Hence, we have an official 'blessing' from him
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7 Mar 2007, at 13:04, Dominique Quatravaux wrote:
I like that. I quite often rub up against inconvenience that would
be solved by being able to have nested groups of tests in a single
test script.
Then you might be interested in checking out
On 07/03/07, Dominique Quatravaux [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fergal Daly a écrit :
On Monday night I finally broke down and implemented nested blocks
for Test::Builder [...] The module is broken in many ways but I'll
post it to CPAN later on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fergal Daly a écrit :
On Monday night I finally broke down and implemented nested blocks
for Test::Builder [...] The module is broken in many ways but I'll
post it to CPAN later on anyway because it'll probably be another
week before I can work
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
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 -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andy Armstrong wrote:
I like that. I quite often rub up against inconvenience that would
be solved by being able to have nested groups of tests in a single
test script.
Then you might be interested in checking out Test::Group.
Regards, Dom
- --
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fergal Daly wrote:
it doesn't seem to include plans for the blocks
Indeed (but Test::Class does). Patches welcome.
and it looks like it doesn't handle groups within groups,
It does: grep for nest in t/*
Best regards,
- --
Tout n'y est pas
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 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
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 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, then to use
Hi,
I've found that using Test::Files in a test script changes the output of
TODO tests in Test::Harness.
== begin test.pl==
use strict;
use warnings;
use lib '../../perl/lib';
use Test::More;
use Test::Files;
plan tests = 2;
TODO: {
local $TODO = TODO Testing;
is(1, 2, a failing test);
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 advantage that
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 = Redirect, permanent = 0
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
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
I'd contribute $200, if that would help.
-M
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
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
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
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 test
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
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
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)
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 web
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 agnostic.
34 matches
Mail list logo
