On 7/16/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
I retract my previous comment. My prototype was, in fact, completely
bogus :)
Let's make that array a reference to a list and everyone will be happy:
can_ok($object, [qw(foo bar baz)], 'reason');
Hopefully that works and makes sense. If
I retract my previous comment. My prototype was, in fact, completely
bogus :)
Let's make that array a reference to a list and everyone will be happy:
can_ok($object, [qw(foo bar baz)], 'reason');
Hopefully that works and makes sense. If !ref $_[1], then just treat it
as a single method name.
> I do not think that prototype means what you think it means.
It means what I think it means. Same syntax as we have currently, no.
You would have to do this:
my @methods = qw(foo bar baz)
can_ok($object, @methods, 'reason')
Instead of:
can_ok($object, qw(foo bar baz), 'reason')
Note that i
On 7/15/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
Worse, it's inconsistent with the rest of the API:
ok$foo == $bar, $REASON;
is$foo, $bar, $REASON;
is_deeply $foo, $bar, $REASON;
And then this:
skip $REASON, $num;
Sadly, it would be hard to change that since so many
On 7/15/06, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
What's the reasoning behind accepting an array, anyway?
Convenience. You almost always use can_ok() with a list of methods.
It also makes calculating the plan a little easier for it to be one
test.
I recall waffling around on the interfa
On 7/15/06, Ovid <[EMAIL PROTECTED]> wrote:
I don't particularly like that this is a silent failure, but I'm not sure of a
robust way to fix that. In any event, I reread the docs a couple of times
before I realized I was being stupid. That suggests to me that this little nit
could be improve
* Jonathan Rockway <[EMAIL PROTECTED]> [2006-07-16 00:45]:
> > can_ok cannot accept a description because it accepts a list.
>
> This could be repaired by re-prototyping can_ok as ([EMAIL PROTECTED]).
I do not think that prototype means what you think it means.
Regards,
--
Aristotle Pagaltzis /
>> Re-reading the man page, it looks like isa_ok and can_ok can't even
>> accept a test description?
>
> can_ok cannot accept a description because it accepts a list.
This could be repaired by re-prototyping can_ok as ([EMAIL PROTECTED]).
What's the reasoning behind accepting an array, anyway?
- Original Message
From: Jonathan Rockway <[EMAIL PROTECTED]>
To: Perl QA List
Sent: Saturday, July 15, 2006 9:33:42 PM
Subject: Re: Fw: Fixing SKIP:
> Worse, it's inconsistent with the rest of the API:
>
> ok$foo == $bar, $REASON;
> is$foo, $ba
> That's incorrect, even though saying "skip X tests" reads naturally
> to me. Since "skip this many for tis reason" is how I mentally think
> of SKIP: blocks, I keep writing them like that, even though it's
> wrong. As mentioned, it fails silently.
Worse, it's inconsistent with the rest of the
On Saturday 15 July 2006 11:35, Ovid wrote:
> If the docs are updated to indicate that the skip message must not consist
> solely of a positive integer, then we're OK. Will that break anything out
> there?
Perhaps if you check both arguments, and then issue a warning if the first
looks solely n
On Jul 15, 2006, at 11:35, Ovid wrote:
That was my initial thought, but there's nothing explicitly wrong
with having a numeric skip message.
No, I said make sure that the *second* argument is numeric. It must
always indicate the number of tests to be skipped.
Best,
David
- Original Message
From: David Wheeler <[EMAIL PROTECTED]>
> Perhaps skip() should be updated to ensure that the second argument
> =~ /^\d+$/;
That was my initial thought, but there's nothing explicitly wrong with having a
numeric skip message. If the docs are updated to indicate tha
- Forwarded Message
From: Ovid <[EMAIL PROTECTED]>
> I have returned to working on the tap parser and stumbled across this
> irritation:
>
> #!/usr/bin/perl
>
> use Test::More tests => 1;
> SKIP: {
>skip "I'm lazy and don't wanna run no tests", 1 if 1;
Well, naturally I had to
On Jul 15, 2006, at 10:52, Ovid wrote:
That's incorrect, even though saying "skip X tests" reads
naturally to me. Since "skip this many for tis reason" is how I
mentally think of SKIP: blocks, I keep writing them like that, even
though it's wrong. As mentioned, it fails silently.
Perha
I have returned to working on the tap parser and stumbled across this
irritation:
#!/usr/bin/perl
use Test::More tests => 1;
SKIP: {
skip "I'm lazy and don't wanna run no tests", 1 if 1;
ok 1, 'We don't get to here';
}
That produces the output:
1..1
# No tests run!
I don't
16 matches
Mail list logo
