Ovid,
> Are you on the latest version of Test::Deep?
Ah, yes. That fixed it. Thanx!
> There are issues with
> previous versions having an isa() sub causing strange failures.
Yeah, I saw something about that on the list, but it didn't occur to
me that having a strange isa() could cause this p
--- Buddy Burden <[EMAIL PROTECTED]> wrote:
>
> then it works again. Am _I_ doing something wrong here? It seems
> like some bizarre interaction between Test::Deep and ... well,
> something. :-)
Are you on the latest version of Test::Deep? There are issues with
previous versions having an isa
Ovid,
> I've just uploaded Test::Most 0.02 to the cpan.
Crap ... you fixed that typo. :)
I meant to let you know about this, but I got totally distracted
before I could pin it down. So now I've got it down fairly sparse
here ... create two files:
# file: Testit.pm
package Testit;
use strict;
Ovid,
> The latter, of course, should assert the number of tests you expected
> to run, not the number of tests you've actually run. Otherwise, it's
> not much better than "no_plan" (except you're still protected from
> premature exits.
Or, to look at it a different way, it would be _exactly_ eq
Hi all,
I've just uploaded Test::Most 0.02 to the cpan. Aside from Test::Warn,
I've added deferred plans using a patch from barefootcoder++ (Buddy
Burden). Example, the following will pass with Test::More 'no_plan':
use Test::More 'no_plan';
ok 1;
exit;
/or, it may make sense to use
> > deferred plans during development, but switch to numeric plans before
> > releasing anything to CPAN.
>
> That's what I do. I have a pair of Vim macros which toggle my plans.
Between no_plan and plan=>, you mean? Well, then, sound
Seems most of this has already been hashed out, but here are a couple
of other comments.
> all my scripts ended with a simple print statement: "ALL
> DONE". I ran the script, and if I saw my ALL DONE at the end, the
> script was fine. If I didn't, I obviously had a problem.
Conceptually this is
Eric Wilhelm wrote:
What it protects you from is dying half-way through the tests
without the harness noticing...
Death is noted by both Test::More and Test::Harness and has been for a
long time
The only way you can abort the test halfway through using no_plan and
get a success is with an e
# from Michael G Schwern
# on Sunday 30 March 2008 22:57:
>> What it protects you from is dying half-way through the tests
>> without the harness noticing...
>Death is noted by both Test::More and Test::Harness and has been for a
> long time
>
>The only way you can abort the test halfway throu
* Michael G Schwern <[EMAIL PROTECTED]> [2008-03-31 08:00]:
> Aristotle Pagaltzis wrote:
>> What it protects you from is dying half-way through the tests
>> without the harness noticing. Of course, that’s by far the
>> most common failure mode.
>
> I don't want to drag out the "plan vs no_plan" arg
Aristotle Pagaltzis wrote:
Note that it doesn’t quite protect you from running too few tests
either. You may botch some conditional in your test program and
end up skipping tests silently, in which case you will still
reach the `all_done()` line, and it’ll look as if all was fine.
The typical a
owards numeric plans for their increased sense of security.
> And/or, it may make sense to use deferred plans during
> development, but switch to numeric plans before releasing
> anything to CPAN.
Yes in all points.
> For myself, I think chromatic's warning is strongly making me
>
On Sunday 30 March 2008 14:57:35 Buddy Burden wrote:
> And/or, it may make sense to use
> deferred plans during development, but switch to numeric plans before
> releasing anything to CPAN.
That's what I do. I have a pair of Vim macros which toggle my plans.
-- c
asy, and when you become more
seasoned, you naturally gravitate towards numeric plans for their
increased sense of security. And/or, it may make sense to use
deferred plans during development, but switch to numeric plans before
releasing anything to CPAN. For myself, I think chromatic's warnin
* Buddy Burden <[EMAIL PROTECTED]> [2008-03-29 20:55]:
> I just think that having code where every time you change
> things in one place, you have to make sure you change something
> somewhere else isn't a good thing. In any other programming
> scenario, I think most everyone would agree with me.
Buddy Burden wrote:
Not criticizing, not claiming my method is better, just looking for
any reasons why this wouldn't work. And, JIC there's some agreement
that it _would_ work, I've already put together a patch for Test::Most
that does it. That is, at the top of your script, you put this:
chromatic,
> Any solution which requires a human being to read and think about the output
> beyond "It's all okay!" or "Something fell!"* is not a long-term solution.
I don't think that's true of this implementation. If the script
doesn't reach the all_done() call, there is a very obvious erro
On Saturday 29 March 2008 12:51:34 Buddy Burden wrote:
> The first is that _during development_, I want to stop my tests on the
> first failure.
Get a better harness.
> The second sticking point is the concept of plans, and here is where I
> really want to understand the reasoning behind it. My
I debated whether or not to post this here for a long time, because I
gather that deferred plans are somewhat of a hot topic on this group.
But finally I decided that I just needed to understand some history
and make sure there's nothing I'm missing here.
First, if you'll bear wi
(For those those who missed the initial conversation, a deferred plan
is like 'no_plan' except the developer specifies the number of tests at
the end of the run instead of Test::Builder just listing how many tests
have run.)
Once again I find that deferred plans would be very helpful.
* Adrian Howard <[EMAIL PROTECTED]> [2007-11-20 16:25]:
> I don't get this. Why is saying "I know this test script
> outputs 8 test results" at the start better than saying it
> at the end?
I assume that if you knew up front how many tests you are going
to run, then you’d just say it.
So you’d de
On Nov 20, 2007, at 9:19 AM, Adrian Howard wrote:
Then you get an error because you have said that you'll defer the
plan, and you didn't.
That there is a "there's a plan coming later" part is what I missed.
Now I get it.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:pe
On 19 Nov 2007, at 23:04, A. Pagaltzis wrote:
[snip]
A deferred plan is clearly not as good as a predeclared plan,
but is definitely much safer than no plan at all.
[snip]
I don't get this. Why is saying "I know this test script outputs 8
test results" at the start better than saying it at t
On 19 Nov 2007, at 23:08, 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? Then you don
On 19 Nov 2007, at 23:04, chromatic 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
when you time
all
- Original Message
> From: Jonathan Rockway <[EMAIL PROTECTED]>
> > 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 proposals
- Original Message
> From: Andy Lester <[EMAIL PROTECTED]>
> 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.
I've not explained myself well. Sorry about that.
T
- Original Message
> From: chromatic <[EMAIL PROTECTED]>
> There's that, and there's that Ovid's tests take too long to run
> when you time all of the startup costs.
The runtime of the tests is completely orthogonal to this problem.
> I'm having trouble convincing myself that the right
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
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
# 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 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
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
40 matches
Mail list logo
