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
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
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
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
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
I'd contribute $200, if that would help.
-M
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
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 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
-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
-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
-
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
-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 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
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 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
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 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
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
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
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
--- 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 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 #
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 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
--- 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
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 -
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
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
(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
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
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
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
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
57 matches
Mail list logo
