# 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, # SKIP ~
- Original Message
From: Eric Wilhelm scratchcomput...@gmail.com
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
# 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 scratchcomput...@gmail.com
I'm not sure anybody *wants* a plan.
snip
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.
# 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 than the
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
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
# 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, then it
# 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 others do
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
# 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?
ewilhelm the computer must use a
- Original Message
From: Eric Wilhelm scratchcomput...@gmail.com
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
2009/1/22 Eric Wilhelm scratchcomput...@gmail.com:
# 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
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
# 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 scratchcomput...@gmail.com
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
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
* Eric Wilhelm scratchcomput...@gmail.com [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
* David E. Wheeler da...@kineticode.com [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
* Eric Wilhelm scratchcomput...@gmail.com [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
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 the Feed::Manager
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 config file
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
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
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
25 matches
Mail list logo
