Andy Armstrong wrote:
> On 8 Mar 2007, at 16:34, Nicholas Clark wrote:
>>> But how do you know "23 ok" if you were never told that it ran ok?
>>
>> Surely one can post-process a regular TAP file to "sparse" output?
>> And only do so if the TAP file is valid non-sparse output.
>
> Or post process
In article <[EMAIL PROTECTED]>, Christopher H. Laco
<[EMAIL PROTECTED]> wrote:
> Paul Beckingham wrote:
> > I'm wanting sparse output:
> >
> > 1..100 sparse
> > 12 not ok
> > 83 not ok
> >
> But how do you know "23 ok" if you were never told that it ran ok?
For your sparse driver,
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > But how do you know "23 ok" if you were never told that it ran ok?
>
> Surely one can post-process a regular TAP file to "sparse" output?
> And only do so if the TAP file is valid non-sparse output.
>
> This seems safer than generating it by def
On 8 Mar 2007, at 16:34, Nicholas Clark wrote:
But how do you know "23 ok" if you were never told that it ran ok?
Surely one can post-process a regular TAP file to "sparse" output?
And only do so if the TAP file is valid non-sparse output.
Or post process it using gzip...
--
Andy Armstrong,
On Thu, Mar 08, 2007 at 11:05:31AM -0500, Christopher H. Laco wrote:
> Paul Beckingham wrote:
> > Because I need to retain the output of all tests, and those files get
> > large, but mostly because of the sheer redundancy.
> >
> >
> >
>
> But how do you know "23 ok" if you were never told tha
Paul Beckingham wrote:
> I'm wanting sparse output:
>
> 1..100 sparse
> 12 not ok
> 83 not ok
>
> Which is three lines of output, instead of 97, but contains the same
> information as:
>
> 1..100
> 1 ok
> 2 ok
> ...
> 12 not ok
> ...
> 83 not ok
> 84 o
I'm wanting sparse output:
1..100 sparse
12 not ok
83 not ok
Which is three lines of output, instead of 97, but contains the same
information as:
1..100
1 ok
2 ok
...
12 not ok
...
83 not ok
84 ok
I'd contribute $200, if that would help.
-M
-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
-
-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 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
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
25 matches
Mail list logo
