Geoffrey Young wrote:
Michael G Schwern wrote:
On Wed, Dec 01, 2004 at 12:44:50AM +0100, Paul Johnson wrote:
plan tests => 14, if => have( "Foo" ) && moon_phase eq "waning";
The downside here, as Geoff alluded to, is that we don't really want the
short circuiting behaviour of &&, since evaluating
Michael G Schwern wrote:
> On Wed, Dec 01, 2004 at 12:44:50AM +0100, Paul Johnson wrote:
>
>>>plan tests => 14, if => have( "Foo" ) && moon_phase eq "waning";
>>
>>The downside here, as Geoff alluded to, is that we don't really want the
>>short circuiting behaviour of &&, since evaluating the op
On Wed, Dec 01, 2004 at 12:44:50AM +0100, Paul Johnson wrote:
> > plan tests => 14, if => have( "Foo" ) && moon_phase eq "waning";
>
> The downside here, as Geoff alluded to, is that we don't really want the
> short circuiting behaviour of &&, since evaluating the operands may give
> useful inform
plan tests => 14, if => have( "Foo" ) && moon_phase eq "waning";
The downside here, as Geoff alluded to, is that we don't really want
the
short circuiting behaviour of &&, since evaluating the operands may
give
useful information as to why the tests are being skipped.
That's fine. You can do thi
On Tue, Nov 30, 2004 at 05:47:31PM -0500, Randy W. Sims wrote:
> Andy Lester wrote:
> >On Tue, Nov 30, 2004 at 11:33:48AM -0800, [EMAIL PROTECTED]
> >([EMAIL PROTECTED]) wrote:
> >
> >>> plan tests => 14, have( "Foo::Wango" ), moon_phase eq "waning",
> >>>etc;
> >
> >
> >All this means is that a
Andy Lester wrote:
On Tue, Nov 30, 2004 at 11:33:48AM -0800, [EMAIL PROTECTED] ([EMAIL PROTECTED])
wrote:
plan tests => 14, have( "Foo::Wango" ), moon_phase eq "waning",
etc;
All this means is that all the following conditions have to be true.
HOW those get evaluated is left to the future. We'
On Tue, Nov 30, 2004 at 10:55:47PM +0100, Tels wrote:
> > Ok, Test::Legacy it is. Now I have to figure out if I want to reimplement
> > Test.pm from scratch or try and wedge a TB object into the existing code.
> > Sean's added a lot of code since last I looked.
>
> I really have to ask :o)
>
> *
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Tuesday 30 November 2004 23:19, Andy Lester wrote:
> On Tue, Nov 30, 2004 at 10:55:47PM +0100, Tels ([EMAIL PROTECTED])
wrote:
> > - From my POV it seems the energy and time to rewrite Test.pm (including
> > fixing the intermidiate breakage) could be
On Tue, Nov 30, 2004 at 10:55:47PM +0100, Tels ([EMAIL PROTECTED]) wrote:
> - From my POV it seems the energy and time to rewrite Test.pm (including
> fixing
> the intermidiate breakage) could be spent for other more worthwhile projects.
Like which ones? What else is lacking?
Foolishly asking,
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Tuesday 30 November 2004 22:10, Michael G Schwern wrote:
> On Tue, Nov 30, 2004 at 09:27:55AM -0600, Andy Lester wrote:
> > On Tue, Nov 30, 2004 at 07:48:00AM -0600, Steve Peters
([EMAIL PROTECTED]) wrote:
> > > I like Test::Compat. Test::Legacy makes
On Tue, Nov 30, 2004 at 09:27:55AM -0600, Andy Lester wrote:
> On Tue, Nov 30, 2004 at 07:48:00AM -0600, Steve Peters ([EMAIL PROTECTED])
> wrote:
> > I like Test::Compat. Test::Legacy makes me think more of the current
> > Test.pm
> > rather than of a new module.
>
> But it's actually going t
On Tue, Nov 30, 2004 at 11:33:48AM -0800, [EMAIL PROTECTED] ([EMAIL PROTECTED])
wrote:
> >plan tests => 14, have( "Foo::Wango" ), moon_phase eq "waning",
> > etc;
All this means is that all the following conditions have to be true.
HOW those get evaluated is left to the future. We're not loc
--- Andy Lester <[EMAIL PROTECTED]> wrote:
> I would just ask that it be done as
>
>plan tests => $n, @list_of_conditions_to_be_met
>
> I would hate to see the 3rd+ parms turn into a meta-language of stuff
> like
>
>plan tests => 14, needs => "Apache::Wango 1.14";
>
> Rather, just make
Andy Lester wrote:
> On Tue, Nov 30, 2004 at 10:36:00AM -0500, Geoffrey Young ([EMAIL PROTECTED])
> wrote:
>
>>anyway, the point of this exercise is to present a few different options for
>>augmenting Test::More's plan(). personally, I really, really like the way
>>Apache::Test::plan() works,
On Tue, Nov 30, 2004 at 10:36:00AM -0500, Geoffrey Young ([EMAIL PROTECTED])
wrote:
> anyway, the point of this exercise is to present a few different options for
> augmenting Test::More's plan(). personally, I really, really like the way
> Apache::Test::plan() works,
I do, too, and I've been wa
hi all.
yesterday on irc we got to discussing adding a feature to Test::More that
Apache-Test has been using for a while. the overall opinion was that the
idea had merit, but we should vet out options here, so comments welcome.
here's the scoop...
over in Apache-Test we allow users to join the p
On Tue, Nov 30, 2004 at 07:48:00AM -0600, Steve Peters ([EMAIL PROTECTED])
wrote:
> I like Test::Compat. Test::Legacy makes me think more of the current Test.pm
> rather than of a new module.
But it's actually going to be Test.pm, not a new module. Just a new
back-end.
--
Andy Lester => [EMA
On Tue, Nov 30, 2004 at 01:46:24AM -0500, Michael G Schwern wrote:
> I'm writing a module to emulate the functionality of Test.pm but with
> a Test::Builder backend so you can use TB-based modules with older tests.
>
> I'm trying to come up with a name. The current working title is Test::Legacy
Michael G Schwern wrote in perl.qa :
> I'm writing a module to emulate the functionality of Test.pm but with
> a Test::Builder backend so you can use TB-based modules with older tests.
>
> I'm trying to come up with a name. The current working title is Test::Legacy.
I like it.
> Test::Compat a
19 matches
Mail list logo
