On Thu, Jul 20, 2006 at 12:39:11AM +0100, Fergal Daly wrote:
Simple question. Given this code:
sub foo {
my $thing;
is($thing-x(), x); # line 4
is($thing-y(), y);
}
$t1 = Thing-new(1);
foo($t1); # line 9
$t2 = Thing-new(2);
foo($t2);
lets say the first is() is going to fail
On Thu, Jul 20, 2006 at 01:38:46AM +0200, demerphq wrote:
Now i consider wrong to be different from broken or buggy. To me
broken and buggy mean that the reporting doesnt do what its supposed
to do. But since I know that what its supposed to do is report where a
given Test::Builder based test
On 7/20/06, chromatic [EMAIL PROTECTED] wrote:
The problem with $Level is that people don't use it correctly. You want to
solve this by providing another element of code that more people will have to
use more frequently and hoping that they use it correctly. I'm not sure that's
a good
On 19 Jul 2006, at 08:18, Steffen Mueller wrote:
Andy Lester schrieb:
At this point, CPANTS rules are getting into the realm of purely
self-pleasuring. If more than a dozen people outside of this
small enclave of people cares whether a module gets a 16 or 17,
I'll be shocked.
- Original Message
From: Gabor Szabo [EMAIL PROTECTED]
I admit, I did not even know that it existed until recently.
I guess I have not read the full documentation of Test::More and Test::Builder
but I assume there are not many that do.
[regarding documentation of
Hi!
On Thu, Jul 20, 2006 at 12:17:02AM +0200, Thomas Klausner wrote:
Please note the for the next few hours cpants.perl.org will show
slightly strange results, as a big reindexing is currently happending.
It's finished by now.
Here's a list of dists failing the new Module::Install metric:
On 20/07/06, chromatic [EMAIL PROTECTED] wrote:
On Wednesday 19 July 2006 18:10, Fergal Daly wrote:
On 20/07/06, chromatic [EMAIL PROTECTED] wrote:
On Thu, Jul 20, 2006 at 12:39:11AM +0100, Fergal Daly wrote:
Simple question. Given this code:
sub foo {
my $thing;
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
I've heard people commenting variants of people will ignore perfectly
good modules unless they have score Foo or people will use crap
modules just because they have score Foo - but I've never actually seen
it happen in Real Life.
Has anybody?
Just a long as we don't show the CPANTS score on
Hi!
On Thu, Jul 20, 2006 at 01:56:36PM +0200, Salve J Nilsen wrote:
Is there a (public) authoritative META.yml spec describing required,
recommended and supported fields?
http://module-build.sourceforge.net/META-spec.html
--
#!/usr/bin/perl
On 20/07/06, Ovid [EMAIL PROTECTED] wrote:
- Original Message
From: Gabor Szabo [EMAIL PROTECTED]
I admit, I did not even know that it existed until recently.
I guess I have not read the full documentation of Test::More and Test::Builder
but I assume there are not many that do.
On 20/07/06, Smylers [EMAIL PROTECTED] wrote:
Fergal Daly writes:
On 20/07/06, chromatic [EMAIL PROTECTED] wrote:
On Wednesday 19 July 2006 18:10, Fergal Daly wrote:
On Thu, Jul 20, 2006 at 12:39:11AM +0100, Fergal Daly wrote:
Simple question. Given this code:
sub
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] =
Salve J Nilsen wrote:
Adam Kennedy wrote:
The presence of lack thereof is more an indication of the scale and
importance of the module, rather than anything you can judge all 10k
modules by.
I'd rather interpret the presence/lack of community pointers as an
indication of how interested
Adam Kennedy wrote:
[...]
I'd actually love to see some statistics, if we are collecting any, of
the good vs bad scores for the various kwalitee elements over time.
That might give us a better idea of how big an impact there is.
Of course, we wouldn't have any stats from before CPANTS
Thomas Klausner wrote:
Hi!
On Thu, Jul 20, 2006 at 01:56:36PM +0200, Salve J Nilsen wrote:
Is there a (public) authoritative META.yml spec describing required,
recommended and supported fields?
http://module-build.sourceforge.net/META-spec.html
Thanks, and it seems there are newer
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 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';
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 Peters
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.
stating the obvious
The exact same benefit as
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.
stating the obvious
The
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.
/stating the obvious
So this gives you protection against not being able to count?
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.
stating the obvious
The exact same benefit as doing a 'plan' at the
beginning, except this would work for scripts
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, 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_plan' in
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 certain
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
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 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
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, but
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 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 20/07/06, chromatic [EMAIL PROTECTED] wrote:
On Thursday 20 July 2006 02:59, Fergal Daly wrote:
There already exist two long-accepted, well-understood, coded, tested,
and debugged ways to answer both questions. I don't see the value in
adding a third, especially when it's not
On 20/07/06, Randy W. Sims [EMAIL PROTECTED] wrote:
Fergal Daly wrote:
I have svn commit access but no idea how to use it prooperly so
attached is a 5 line patch to Test::Builder to make it say things like
I think I would vote for this, but maybe with a setting or environment
variable to
On Thursday 20 July 2006 13:50, Fergal Daly wrote:
Example code please.
You *quoted* my example code in multiple messages, including this one.
You're saying there's a situation where using
$Level produces the incorrect output. I'm saying there isn't.
I don't know what else to call a stack
While using page_link_ok it checks all the links on the page,
including those that point to external sites.
It is bth unpolite - why hit their site every time I run my test script and
when I am working off line it generates false errors.
What would be the correct and easy way to test only links
On Jul 20, 2006, at 4:42 PM, Gabor Szabo wrote:
What would be the correct and easy way to test only links that are
internal to
the site. Maybe a
page_internal_links_ok() method?
How would you have it determine what's internal?
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com =
On 20/07/06, chromatic [EMAIL PROTECTED] wrote:
On Thursday 20 July 2006 13:50, Fergal Daly wrote:
Example code please.
You *quoted* my example code in multiple messages, including this one.
Your example does not produce any incorrect output. Nothing I have
seen in any thread has produced
* 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];
for (@countries) {
* 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 code I
On Thursday 20 July 2006 14:46, Fergal Daly wrote:
Your example does not produce any incorrect output.
Perhaps incorrect is a very poor word choice, but I certainly consider the
stack trace behavior potentially unhelpful and potentially misleading.
I will make one more attempt to demonstrate.
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.
[cc'd to perl-qa for awareness of the issue]
The switch to version objects in Module::Build means that the generated
META.yml now has this:
name: Class-InsideOut
version: !!perl/hash:Module::Build::Version
original: 1.00
version:
- 1
- 0
That can't be good for backwards
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
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
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.
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 years of
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 wanted and
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, thinking That
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. Yes,
I
* 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' );
}
BEGIN {
John Peacock wrote:
David Golden wrote:
[cc'd to perl-qa for awareness of the issue]
The switch to version objects in Module::Build means that the generated
META.yml now has this:
Is this with or without YAML itself loaded (so I know where to start)?
I did a little digging and this line
On Jul 20, 2006, at 9:07 PM, David Golden wrote:
$node is a YAML::Node and the EXISTS function only checks for
things stored in the NODE property, not the HASH property. I'm not
sure exactly what those two are supposed to be representing, but
the point is that the exists
On 7/21/06, Andy Lester [EMAIL PROTECTED] wrote:
On Jul 20, 2006, at 4:42 PM, Gabor Szabo wrote:
What would be the correct and easy way to test only links that are
internal to
the site. Maybe a
page_internal_links_ok() method?
How would you have it determine what's internal?
When
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
55 matches
Mail list logo
