On Fri, Jan 23, 2009 at 01:12:22AM +0100, Aristotle Pagaltzis wrote:
> Although most of the time I find ways not to have to do that, and
> still be able to declare a plan. Data-driven tests work wonders
> for this. The rest of the time I use a variety of tricks to
> reduce the pain, such as this o
On Fri, Jan 23, 2009 at 01:00:59AM +0100, Aristotle Pagaltzis wrote:
> * 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
# from Aristotle Pagaltzis
# on Thursday 22 January 2009 16:00:
>> 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 th
# from Michael G Schwern
# on Thursday 22 January 2009 19:15:
>Nope. For my money the best solution to the problem of having a
> reliable plan without having to count the number of tests is simply
> the done_testing() flag.
I like the done_testing() flag and have even implemented ad-hoc versions
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 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
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
* 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 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
* Ovid [2009-01-21 23:15]:
> Now that I think about it, the only reason we have this:
>
> multisub skip(Str $reason);
>
> ... 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
On Jan 21, 2009, at 2:13 PM, Ovid wrote:
... 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.
Sound good?
Yes, but can the numbe
- Original Message
> From: chromatic
> *Every* time I use skip() in Perl 5, I have to remember the rule that the
> *description* comes first, and the the test number. I only fail to make this
> mistake if I've already made it within the past five minutes.
Agreed. I'm bitten by this
On Wednesday 21 January 2009 13:47:24 Ovid wrote:
> If a programmer listed '3' as their skip reason, that would be interpreted
> as the number of tests to skip. Admittedly, it would be stupid for
> programmers to do that (and unlikely that they would), but we shouldn't be
> telling them "here's an
On Jan 21, 2009, at 1:47 PM, Ovid wrote:
What do you mean?
If a programmer listed '3' as their skip reason, that would be
interpreted as the number of tests to skip. Admittedly, it would be
stupid for programmers to do that (and unlikely that they would),
but we shouldn't be telling them
- Original Message
> From: David E. Wheeler
> > # Won't get called unless the string has a non-digit in it
> > multisub skip( Str $desc where { $desc ~~ /\D/ } );
> >
> > Thus, you could call this and it will still DWIM:
> >
> > if $cond {
> > skip "3";
> > else {
> > #
On Jan 21, 2009, at 10:47 AM, Ovid wrote:
However, that's going to break if $count is a string, right?
Thought this might work as a heuristic for that third definition:
# Won't get called unless the string has a non-digit in it
multisub skip( Str $desc where { $desc ~~ /\D/ } );
Thus, you
Background: I know many of you aren't working with Perl 6 and if you're not
interested, feel free to ignore :)
I'm working on Test.pm, the core Perl 6 testing module. I'm trying to get it
up to speed, including diagnostics. What follows is a tiny problem with &skip.
The skip multisub in Raku
31 matches
Mail list logo
