- Original Message
> From: David E. Wheeler
> > ... is because we want a default value of 1 for the number of tests
> > to skip. Eliminate that default and the entire problem goes away.
> > You must *always* specify the number of tests to skip. $reason is
> > optional.
> >
> > So
# from Ovid
# on Wednesday 21 January 2009 10:47:
> multi sub skip() is export() { proclaim(1, "# SKIP"); }
> multi sub skip($desc) is export() { proclaim(1, "# SKIP " ~
> $desc); } multi sub skip($count, $desc) is export() {
> for 1..$count {
> proclaim(1, "# S
- Original Message
> From: Eric Wilhelm
> Passing a number of tests to skip() is an untested failure waiting to
> happen.
>
> Perhaps it is still no easy task to count the tests in a block, but
> making humans count them is just asking for errors.
We already have 'plan tests => 33'.
# from Ovid
# on Thursday 22 January 2009 02:00:
>The programmer still has to count if the programmer wants a plan.
I'm not sure anybody *wants* a plan. A way to ensure that every test
ran or accurate progress reporting, yes. It seems to me that some are
just willing to suffer counting their
Eric Wilhelm wrote:
I suppose "if($whatever) { some_test() } else { alternate_test()}"
would complicate automatic counting. But, you have to go down one
branch.
But there's no protection that one branch doesn't have a different number of
tests than the other.
The only impossible spot is w
- Original Message
> From: Eric Wilhelm
> I'm not sure anybody *wants* a plan.
Lots of people want plans. Lots of people don't want plans. That's
not an argument I expect anybody is going to *win* (even if they're right).
This has been argued to death. Many times. Over and over.
# from Michael Peters
# on Thursday 22 January 2009 09:55:
>> I suppose "if($whatever) { some_test() } else { alternate_test()}"
>> would complicate automatic counting. But, you have to go down one
>> branch.
>
>But there's no protection that one branch doesn't have a different
> number of tests
On Jan 22, 2009, at 11:06 AM, Eric Wilhelm wrote:
That still doesn't imply that we can't somehow count the number of
tests
with a computer instead of relying on humans to screw it up. If some
combination of static analysis and early runtime can come up with a
count, then it becomes possible t
# from Ovid
# on Thursday 22 January 2009 11:01:
>>>The programmer still has to count if the programmer wants a plan.
>
>> I'm not sure anybody *wants* a plan.
>
unsnip:
>>A way to ensure that every test ran or accurate progress reporting,
>>yes. It seems to me that some are just willing to suffe
On Jan 22, 2009, at 1:27 PM, Eric Wilhelm wrote:
I personally use no_plan only because I can't be bothered to manually
count things and don't want to assume that the number of tests run on
*my* computer is somehow a universal constant.
I'm glad you find no_plan useful. Many others do as wel
# from David E. Wheeler
# on Thursday 22 January 2009 11:15:
>> That still doesn't imply that we can't somehow count the number of
>> tests
>> with a computer instead of relying on humans to screw it up. If
>> some combination of static analysis and early runtime can come up
>> with a count, th
# from Andy Lester
# on Thursday 22 January 2009 11:31:
>> I personally use no_plan only because I can't be bothered to
>> manually count things and don't want to assume that the number of
>> tests run on *my* computer is somehow a universal constant.
>
>I'm glad you find no_plan useful. Many oth
On Jan 22, 2009, at 1:34 PM, Eric Wilhelm wrote:
I personally use no_plan only because I can't be bothered to
manually count things and don't want to assume that the number of
tests run on *my* computer is somehow a universal constant.
I'm glad you find no_plan useful. Many others do as well
# from Andy Lester
# on Thursday 22 January 2009 11:35:
>> Perhaps I'm being unclear. I do not find either 'no_plan' or 'plan'
>> to be useful in their current state.
>
>Yes, but many others do.
Well, are we just accepting limitations and refusing to dream?
the computer must use a $number.
- Original Message
> From: Eric Wilhelm
> >> Perhaps I'm being unclear. I do not find either 'no_plan' or 'plan'
> >> to be useful in their current state.
> >
> >Yes, but many others do.
>
> Well, are we just accepting limitations and refusing to dream?
Show us the code.
No, don'
2009/1/22 Eric Wilhelm :
> # from Andy Lester
> # on Thursday 22 January 2009 11:35:
>
>>> Perhaps I'm being unclear. I do not find either 'no_plan' or 'plan'
>>> to be useful in their current state.
>>
>>Yes, but many others do.
>
> Well, are we just accepting limitations and refusing to dream?
On Jan 22, 2009, at 1:08 PM, Fergal Daly wrote:
Assuming the static analysis was correct, it would always produce the
correct number thus would be equivalent to no_plan. For me, the
purpose of the plan is not to detect failures that cause early exits -
it can do that but the test harness also lo
# from Ovid
# on Thursday 22 January 2009 13:01:
>Show us the code.
>
>No, don't show us an "ideal" API; show us the real, actual code. Even
> a simple proof of concept would be fine. Seriously. Show us the
> code.
I'm not sure whether this would qualify as either an ideal API or real
actual
- Original Message
> From: Eric Wilhelm
> Other details of the implementation will be up to the implementor. If
> that's me, I suppose I should have learned by now not to bother making
> a suggestion.
Eric, I know I come across as rather brusque at times and I apologize; it's
nothi
On Jan 22, 2009, at 2:24 PM, Eric Wilhelm wrote:
Or thereabouts. The business of skipping, todoing, counting,
planning,
and ensuring that all tests actually run is going to involve various
details and possibly even get into the limitations of TAP -- but you
now have every chunk of tests setup
* Eric Wilhelm [2009-01-22 18:55]:
> Pretend for a moment that the number of tests could
> automatically be counted by the interpreter (e.g. at
> the parse/compile stage.)
There’s no need to pretend. Either you can tell us how to solve
the halting problem and then it’s possible, or you can’t and
* David E. Wheeler [2009-01-22 20:20]:
> There will be loops with tests in them, and the number of
> iterations of the loop will be independent of the code in the
> test script, making it impossible to actually count the number
> of tests with a computer until the tests have actually been
> run. W
* Eric Wilhelm [2009-01-22 18:55]:
> I'm not sure anybody *wants* a plan.
I do.
> A way to ensure that every test ran or accurate progress
> reporting, yes.
I also want to be sure that no unexpected extra tests ran.
> It seems to me that some are just willing to suffer counting
> their tests t
Ovid wrote:
> For example, with your code (as I understand it):
>
> test {
> my $manager = Feed::Manager->new($some_uri);
> foreach my $resource ($manager->resources) {
> ok my $result = $manager->get($resource), "$resource should
> work";
> }
> }
>
> Imagine that th
Eric Wilhelm wrote:
>>> The only impossible spot is when tests are inside e.g. a
>>> runtime dispatched method, no? (And, given the procedural paradigm,
>>> that seems to be an odd case.)
>> No, that's not odd at all. Any data driven testing system will be that
>> way. Tests are run based on some
Justin DeVuyst wrote:
> Hello,
>
> I was told this might be a place to get information about
> upcoming Test::Builder changes.
>
> I'd like to know if and when Test::Builder will officially
> support true plan at end. The current version of
> Test::Builder reports 1..$seen_tests instead of
> 1..
On Jan 22, 2009, at 5:22 PM, Michael G Schwern wrote:
Because, in Perl and other languages, until you run it you can't
know what
class $object is going to be, or what its inheritance tree will look
like, and
once you do figure out which run_tests() will run (if any) you're
back to the
prob
Please, can we stop going over plans again?
Every minute spent yapping about whether plans are good or not is a
minute that could be spent doing something useful, like working on
Test.pm for Perl 6.
This has come up a few times a year for the last five years at least,
and I am not exagge
David E. Wheeler wrote:
> I'm in complete agreement with you here, but just to clarify something
> that became clear to me only when Eric and I discussed it on IRC, what
> Eric is thinking of is basically turning a loop of unknown length into a
> single test. So to use your examples, it would be:
>
On Jan 22, 2009, at 7:04 PM, Andy Lester wrote:
Please, can we stop going over plans again?
Every minute spent yapping about whether plans are good or not is a
minute that could be spent doing something useful, like working on
Test.pm for Perl 6.
You're going to have to be a bit tolerant
On Jan 22, 2009, at 11:23 PM, David E. Wheeler wrote:
people see Perl 6 as an opportunity to rethink things.
Except that Perl 6 isn't changing TAP.
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance
On Jan 22, 2009, at 10:02 PM, Andy Lester wrote:
On Jan 22, 2009, at 11:23 PM, David E. Wheeler wrote:
people see Perl 6 as an opportunity to rethink things.
Except that Perl 6 isn't changing TAP.
No, but there really wasn't any talk about changing TAP in that
thread. It was implied, but
- Original Message
> From: David E. Wheeler
> To: Andy Lester
> Cc: Michael G Schwern ; Eric Wilhelm
> ; perl-qa@perl.org
> Sent: Friday, 23 January, 2009 6:16:25
> Subject: Re: Let us stop rehashing plans
>
> On Jan 22, 2009, at 10:02 PM, Andy Lester wrote:
>
> > On Jan 22, 2009, at
33 matches
Mail list logo
