> In article <[EMAIL PROTECTED]>, Michael G Schwern
> <[EMAIL PROTECTED]> wrote:
>
> > brian d foy wrote:
> > > Fair enough. Can you make a list of the last versions of all of those
> > > that should work with Perl5.005? I suppose that's the current list
> > > right now.
I would suggest for those
In article <[EMAIL PROTECTED]>, Michael G Schwern
<[EMAIL PROTECTED]> wrote:
> brian d foy wrote:
> > Fair enough. Can you make a list of the last versions of all of those
> > that should work with Perl5.005? I suppose that's the current list
> > right now.
>
> Pretty much. If anyone wants to pu
brian d foy wrote:
> Fair enough. Can you make a list of the last versions of all of those
> that should work with Perl5.005? I suppose that's the current list
> right now.
Pretty much. If anyone wants to put in the effort to make such a list they
can, knock yourself out.
--
...they shared one
In article <[EMAIL PROTECTED]>, Michael G Schwern
<[EMAIL PROTECTED]> wrote:
> This is an announcement that my modules will no longer try to be backwards
> compatible with 5.5.x.
Fair enough. Can you make a list of the last versions of all of those
that should work with Perl5.005? I suppose tha
On Mon, 2007-11-19 at 17:08 -0600, Andy Lester wrote:
> On Nov 19, 2007, at 5:04 PM, A. Pagaltzis wrote:
>
> > A deferred plan is clearly not as good as a predeclared plan,
> > but is definitely much safer than no plan at all.
>
> But what if something blows up before getting to the deferred plan
* Andy Lester <[EMAIL PROTECTED]> [2007-11-20 00:10]:
> But what if something blows up before getting to the deferred
> plan? Then you don't know.
How could you *not* know? The TAP stream says “I’m gonna supply
a plan at the end, I just don’t know how many tests I’m going to
run yet.” How would th
On Nov 19, 2007, at 5:04 PM, A. Pagaltzis wrote:
A deferred plan is clearly not as good as a predeclared plan,
but is definitely much safer than no plan at all.
But what if something blows up before getting to the deferred plan?
Then you don't know. You've bypassed having a plan.
I wou
* Andy Lester <[EMAIL PROTECTED]> [2007-11-19 23:17]:
> I guess I'm not seeing why a deferred plan is better than no
> plan at all.
At a minimum, because the harness expects a plan. If you exit
prematurely, it can at least detect that no plan was given,
whereas if you test without a plan, it kno
On Monday 19 November 2007 14:11:35 Andy Lester wrote:
> I guess I'm not seeing why a deferred plan is better than no plan at
> all. Seems to me the whole point of a plan is that you know up front
> how many they're gonna be.
There's that, and there's that Ovid's tests take too long to run w
On Monday 19 November 2007 14:30:51 Jonathan Rockway wrote:
> I think the real solution, though, is to agree that the perl interpreter
> without all of the core modules installed isn't Perl. (I'm not a big
> fan of core modules, but the concept is especially worthless if you
> can't depend on the
On Sun, 2007-11-18 at 18:51 -0800, Matisse Enzer wrote:
> On Nov 18, 2007, at 7:25 AM, Andreas J. Koenig wrote:
> >>
> > Even if it's in the perl core, the developer may have compiled with
> >
> >-Dnoextensions=Encode
> >
> > In such a case Encode is not present. I have skipped Encode many tim
Jonathan Rockway wrote:
> On Mon, 2007-11-19 at 13:06 +, Andy Armstrong wrote:
>> I think we really need to reach a decision on
>>
>> http://testanything.org/wiki/index.php/Test_Groups versus
>> http://testanything.org/wiki/index.php/Test_Blocks
>
> It looks like the con on both of these propo
I guess I'm not seeing why a deferred plan is better than no plan at
all. Seems to me the whole point of a plan is that you know up front
how many they're gonna be.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Mon, 2007-11-19 at 13:06 +, Andy Armstrong wrote:
> On 19 Nov 2007, at 11:04, Ovid wrote:
> > I could get around this by loading all of the YAML files and
> > checking their count, but then I'd have to load them *again* when I
> > run the tests and that defeats the purpose of speeding u
On Nov 19, 2007, at 10:28 AM, Geoffrey Young wrote:
"BAIL_ON_FAIL" approach to running a test suite - a settings that
determines how many failures before the whole test run stops. Default
would be to keep running no matter how many failures, but you could
set
it to 1 and then bam, the whole
Matisse Enzer wrote:
>
> On Nov 18, 2007, at 3:50 AM, Michael G Schwern wrote:
>
>>
>> I start at the top, read the first few failures, fix them and rerun.
>> I ignore
>> the bulk of a really large failure as they're probably just cascades
>> of the
>> one mistake.
>
> This reminds me - I was
On Nov 19, 2007, at 1:36 AM, Ovid wrote:
- Original Message
From: Matisse Enzer <[EMAIL PROTECTED]>
This reminds me - I was wondering what it would take to implement a
"BAIL_ON_FAIL" approach to running a test suite
...
Should be fairly easy to implement with the new Test::Harne
# from Ovid
# on Monday 19 November 2007 03:04:
>That avoids the overhead of reloading perl and the modules multiple
> times. However, each .yml file defines its own test count and I
> don't want 'no_plan'.
So, you write a custom 'exec' program which starts a daemon (the first
time (e.g. checks
On 19 Nov 2007, at 11:04, Ovid wrote:
I could get around this by loading all of the YAML files and
checking their count, but then I'd have to load them *again* when I
run the tests and that defeats the purpose of speeding up the test
suite.
I think we really need to reach a decision on
h
On 19 Nov 2007, at 09:36, Ovid wrote:
Should be fairly easy to implement with the new Test::Harness. What
syntax would be desired? Also, it seems to me that you've two
different cases. Have the entire suite BAIL_ON_FAIL or have an
individual test program halt on failure. The latter seems
On 19 Nov 2007, at 11:04, Ovid wrote:
[snip]
That avoids the overhead of reloading perl and the modules multiple
times. However, each .yml file defines its own test count and I
don't want 'no_plan'. What I really want to do is this:
use Test::More 'deferred_plan'
my $plan = 0;
fore
On 18 Nov 2007, at 11:50, nadim khemir wrote:
Hi, This mail is not discussing what quality and what test quality
is. It is
about what quality our 'test files' have.
I run Test::Fixme, Kwalitee, perl::Critic, etc ... on my modules
but none of
them is ran on my tests. tests have a tendency
Hi all,
Trying to speed up some tests at work. We have a bunch of test files like this:
t/foo/bar/baz.yml
t/foo/bar/baz.t
So each .yml file has a corresponding .t file. However, each .t file is (more
or less) identical. It looks like I can get the test time down from 10 minutes
to about t
- Original Message
> From: Matisse Enzer <[EMAIL PROTECTED]>
> This reminds me - I was wondering what it would take to implement a
> "BAIL_ON_FAIL" approach to running a test suite - a settings that
> determines how many failures before the whole test run stops. Default
> would be t
- Original Message
> From: Matisse Enzer <[EMAIL PROTECTED]>
> I organize my test files using an approach similar to nUnit - I
> create
> a bunch of subroutines that each do a few assertions, and that call
> set_up() and tear_down().
...
> sub test_foo {
> my $foo = set_up();
>
25 matches
Mail list logo
