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
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 dis
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 for
claiming this namespace. Does anyone have any thoug
Adam Kennedy wrote:
Its O(1) vs O(n). We do the work once to make "no plan" safer,
everybody benefits for happily ever after. Your argument sounds like
the things I had to deal with when I introduced Test::More. "Why
should we load a module with all these functions when I can just write
'pr
(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
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 could incorporate our new thoughts on how to handle
testing and not have
On 7 Mar 2007, at 11:15, Ovid wrote:
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 could incorporate our new thoughts on how to handle
testing and not have to worry as much about backwards c
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 -
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Where does TAP::Tests fit in? D'you mean as an alternative to
> Test::More or whatever?
Yes, an alternative to Test::More. Some thoughts:
* Output everything to STDOUT (thereby avoiding the buffering
problems that many experience)
* Eliminate
On 7 Mar 2007, at 11:56, Ovid wrote:
* Wash my dishes
OK :)
And what about its relationship to all the other existing testing
modules? Are they cut adrift? Does it replace Test::Builder?
--
Andy Armstrong, hexten.net
On 07/03/07, Ovid <[EMAIL PROTECTED]> wrote:
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Where does TAP::Tests fit in? D'you mean as an alternative to
> Test::More or whatever?
Yes, an alternative to Test::More. Some thoughts:
Where is it?
* Output everything to STDOUT (thereby avoidin
On 7 Mar 2007, at 12:10, Fergal Daly wrote:
* nested blocks, each with it's own plan (or no plan)
eg
1..3
1 OK
2 1..2 # start a block
2.1 1..3 # start another block
2.1.1 OK
2.1.2 OK
2.1.3 OK
2.1 OK # inner block was all good
2.2 OK
2 OK # outer block was all good
3 1..3
3.1 OK
3.2 OK
3 NOT OK #
--- Fergal Daly <[EMAIL PROTECTED]> wrote:
> On 07/03/07, Ovid <[EMAIL PROTECTED]> wrote:
> > --- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> >
> > > Where does TAP::Tests fit in? D'you mean as an alternative to
> > > Test::More or whatever?
> >
> > Yes, an alternative to Test::More. Some thought
On 07/03/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Mar 2007, at 12:10, Fergal Daly wrote:
> * nested blocks, each with it's own plan (or no plan)
> eg
> 1..3
> 1 OK
> 2 1..2 # start a block
> 2.1 1..3 # start another block
> 2.1.1 OK
> 2.1.2 OK
> 2.1.3 OK
> 2.1 OK # inner block was all g
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 si
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 Armst
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
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' fro
-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 Tes
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 wo
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 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, the
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 advanta
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: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: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 agai
> 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: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
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: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
> > 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 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' o
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
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
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 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
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 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
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
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
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
Julien Beasley wrote:
Hi,
I've found that using Test::Files in a test script changes the output of
TODO tests in Test::Harness.
Here's the problem.
$ perl -wle 'use Test::Files; print Test::Builder->new->exported_to'
Test::Files
exported_to() is the mechanism Test::Builder uses to guess in
Adam Kennedy wrote:
Still no obvious place to put it, other than on it's own in Test::NewOk...
Umm, your own Test::Object? Though that seems to be a reimplementation of
Test::Class with a clumsy (sorry, looks that way to me having to write 3-4
lines of code per test method) test registration
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
On Mar 5, 2007, at 1:58 PM, Eric Wilhelm wrote:
# from Ricardo SIGNES
# on Monday 05 March 2007 10:09 am:
* brian d foy <[EMAIL PROTECTED]> [2007-03-04T12:09:26]
... without me having to
change the META.yml in all of my distributions then re-uploading
them all.
So, for some subset of META
57 matches
Mail list logo
