- 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
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
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 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
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:
>
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
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
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..
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
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 [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
* 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]:
> 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
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
- 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
# 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
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
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?
- 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'
# 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.
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: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
# 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
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 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 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 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
- 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.
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
# 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
- 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 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: 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
33 matches
Mail list logo
