On Thu, Jul 20, 2006 at 04:01:00PM -0700, Michael G Schwern wrote:
> On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> >If I am not mistaken the problem with no_plan is that the test script
> >might exit before actually running all the tests you wanted and Harness
> >won't notice it.
>
> PS In
I'm beaten over this argument. After a little thought,
I agree with Andy and chromatic that the "plan at the end"
buys very little and can disturb the simplicity of the testing
API for nothing.
After all, it is very easy to write a code like that
and rewrite our examples.
use Test::More 'no_
On 7/20/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
use Test::More;
plan tests => my $tests;
{
require_ok( 'MyModule' );
my $obj = MyModule->new();
isa_ok( $obj, 'MyModule' );
}
BEGIN { $tests += 3 }
[snip clever code]
Like Schwern said, this stuff
On 7/20/06, David Wheeler <[EMAIL PROTECTED]> wrote:
You probably could have used Test::More->builder->expected_tests to
set the sample sized based on whatever value you put into the plan.
I didn't know about Test::Builder->expected_tests, but from the code
of Test::Builder 0.33 it looks like i
On 7/21/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> If I am not mistaken the problem with no_plan is that the test script
> might exit before actually running all the tests you wanted and Harness
> won't notice it.
PS In all my years of
* Michael G Schwern <[EMAIL PROTECTED]> [2006-07-21 01:30]:
> On 7/20/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> >use Test::More;
> >
> >plan tests => my $tests;
> >
> >{
> >require_ok( 'MyModule' );
> >my $obj = MyModule->new();
> >isa_ok( $obj, 'MyModule' );
On 21/07/06, chromatic <[EMAIL PROTECTED]> wrote:
On Thursday 20 July 2006 16:57, Fergal Daly wrote:
> On 21/07/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Test an XS component. Segfaults don't call done_testing_now().
> >
> > Yes, that happened to me last night. Yes, I had 'no_plan' active.
On Thursday 20 July 2006 16:57, Fergal Daly wrote:
> On 21/07/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Test an XS component. Segfaults don't call done_testing_now().
> >
> > Yes, that happened to me last night. Yes, I had 'no_plan' active. Yes,
> > I noticed it as a happy accident, thinkin
On 21/07/06, chromatic <[EMAIL PROTECTED]> wrote:
On Thursday 20 July 2006 16:01, Michael G Schwern wrote:
> On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > If I am not mistaken the problem with no_plan is that the test script
> > might exit before actually running all the tests you want
On Thursday 20 July 2006 16:01, Michael G Schwern wrote:
> On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > If I am not mistaken the problem with no_plan is that the test script
> > might exit before actually running all the tests you wanted and Harness
> > won't notice it.
> PS In all my
On 7/20/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
use Test::More;
plan tests => my $tests;
{
require_ok( 'MyModule' );
my $obj = MyModule->new();
isa_ok( $obj, 'MyModule' );
}
BEGIN { $tests += 3 }
Pretty sneaky. This is now in the FAQ.
http://pe
On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
If I am not mistaken the problem with no_plan is that the test script
might exit before actually running all the tests you wanted and Harness
won't notice it.
PS In all my years of testing I have never been bitten by this in the
real world whi
On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
If I am not mistaken the problem with no_plan is that the test script
might exit before actually running all the tests you wanted and Harness
won't notice it.
That's what I wanted to avoid.
So maybe if there was a mode where Test::Builder did n
On 7/20/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
Exactly. :-) Take a look at, for instance, IPC::Run's test cases...
an array of sub{} blocks, some of which get skipped over on certain OS'es.
It'd be really easy to accidentally put to ok()'s in one sub{} block and
screw up the count
* Tyler MacDonald <[EMAIL PROTECTED]> [2006-07-20 21:15]:
> Take a look at, for instance, IPC::Run's test cases... an array
> of sub{} blocks, some of which get skipped over on certain
> OS'es. It'd be really easy to accidentally put to ok()'s in one
> sub{} block and screw up the count.
In the co
* Adriano Ferreira <[EMAIL PROTECTED]> [2006-07-20 22:10]:
> use Test::More;
>
> subplan tests => 2;
>
> require_ok('MyModule');
> my $obj = MyModule->new();
> isa_ok($obj, 'MyModule');
>
> my @cities = ("Brasilia", "Rio de Janeiro", "Salvador");
>
> subplan tests => [EMAIL PROTECTED];
>
> fo
On Jul 20, 2006, at 13:38, Adriano Ferreira wrote:
When I made changes, I usually
decreased radically the size of the sample to not be drowned in "not
ok". When everything was alright, I returned to sample sizes of 100 or
so. It would have been easier if I could count with simple expressions
and
On 7/20/06, chromatic <[EMAIL PROTECTED]> wrote:
I don't understand this. I have a Vim macro that switches between:
use Test::More 'no_plan';
... and:
use Test::More tests => 1;
When I work on a test suite, I switch off the plan. When I finish, I look at
the number of tests
On 7/20/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Jul 20, 2006, at 2:45 PM, Adriano Ferreira wrote:
> Ok, that's weird. But it may occasionally have usefulness. Gabor
> started the thread with the idea of having a test against web pages,
> which he doesn't know how many at the beginning, bu
On Thursday 20 July 2006 13:05, Adriano Ferreira wrote:
> Sometimes, I would like to
> have something like that below so that I don't need to think about how
> to compute the number of tests beforehand
I don't understand this. I have a Vim macro that switches between:
use Test::More 'no
On 7/20/06, Hakim Cassimally <[EMAIL PROTECTED]> wrote:
Restructuring your tests (moving OS-dependent, skippable sections to
their own scripts for example) might make the requirement for a
deferred plan seem less important ?
Writing tests is harder. Writing code is more rewarding to the heart.
On Jul 20, 2006, at 2:45 PM, Adriano Ferreira wrote:
Ok, that's weird. But it may occasionally have usefulness. Gabor
started the thread with the idea of having a test against web pages,
which he doesn't know how many at the beginning, but which may be
verified at the end - his count against Te
On 7/20/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Jul 20, 2006, at 2:19 PM, Adriano Ferreira wrote:
> was emitted, it would mean the test *should* tell the plan at the end.
> If it doesn't, it is a failure. I don't think this is no protection.
> It may be an improvement to 'no_plan' in cert
On 7/20/06, Adriano Ferreira <[EMAIL PROTECTED]> wrote:
When something like
> >>> use Test::More tests => 'defer';
was emitted, it would mean the test *should* tell the plan at the end.
If it doesn't, it is a failure. I don't think this is no protection.
It may be an improvement to 'no_pl
On Jul 20, 2006, at 2:19 PM, Adriano Ferreira wrote:
was emitted, it would mean the test *should* tell the plan at the end.
If it doesn't, it is a failure. I don't think this is no protection.
It may be an improvement to 'no_plan' in certain circumstances.
What circumstance would that be?
--
On 7/20/06, Michael Peters <[EMAIL PROTECTED]> wrote:
>> What benefit would that give? plan() is nice because it provides protection
>> against you test script exiting prematurely.
>
>
> The exact same benefit as doing a 'plan' at the
> beginning, except this would work for scripts that don't k
Michael Peters <[EMAIL PROTECTED]> wrote:
> > If the calculated result used in the
> > 'plan' at the end does not match the number of tests actually run, then you
> > know you've got a problem with your test code.
> >
>
> So this gives you protection against not being able to count?
Exac
Tyler MacDonald wrote:
> Michael Peters <[EMAIL PROTECTED]> wrote:
>>> use Test::More tests => 'defer';
>>>
>>> and then
>>>
>>> plan past_tests => $n;
>> What benefit would that give? plan() is nice because it provides protection
>> against you test script exiting prematurely.
>
>
Michael Peters <[EMAIL PROTECTED]> wrote:
> > use Test::More tests => 'defer';
> >
> > and then
> >
> > plan past_tests => $n;
>
> What benefit would that give? plan() is nice because it provides protection
> against you test script exiting prematurely.
The exact same benefit as do
Adriano Ferreira wrote:
> It would be something different, like
>
> use Test::More tests => 'defer';
>
> and then
>
> plan past_tests => $n;
What benefit would that give? plan() is nice because it provides protection
against you test script exiting prematurely.
--
Michael Peter
On 7/20/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> On the other hand I can count them during the test and can tell
> Test::More that I was actually expecting $n tests.
This is exactly how no_plan works.
use Test::More 'no_plan';
Te
On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
As this is a live site with user created pages I don't know up front how
many pages I am going to test thus I don't know the number of tests
before I run them.
On the other hand I can count them during the test and can tell
Test::More that I was
On Jul 20, 2006, at 9:47 AM, Gabor Szabo wrote:
Can I somehow do this - promise at the beginning that I will tell
my plan at the end. (It should consider it a failuer if I don't
give plan in the end.)
No. That's not how plans work.
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.c
I have a nasty workaround.
# at the beginning
my $test_allowance = 100;
plan tests => $test_allowance;
# run the tests here and for each test also execute
$test_allowance--;
# in the end
ok(1) while $test_allowance--;
I really hope there is a nicer way to do it.
Gabor
http://www.szabgab.
While testing a *live* web site I crawl through several pages.
For each page I would like to do some tests
(e.g. it has a link to home, its HTML is valid, etc.)
As this is a live site with user created pages I don't know up front how
many pages I am going to test thus I don't know the number of t
35 matches
Mail list logo
