On Friday 23 January 2009 23:25:05 Michael G Schwern wrote:
> chromatic wrote:
> > That assumes that the TAP parser has some degree of control over the TAP
> > emitter, which is an assumption I would like people to stop making
> > universally.
> > I don't cut off and discard the ends of roasts,
chromatic wrote:
> On Friday 23 January 2009 20:48:57 Michael G Schwern wrote:
>
>> But these days a TAP parser can catch most premature exits by just looking
>> at the exit code of the test, so the plan is less useful than it once was.
>
> That assumes that the TAP parser has some degree of cont
On Friday 23 January 2009 20:48:57 Michael G Schwern wrote:
> But these days a TAP parser can catch most premature exits by just looking
> at the exit code of the test, so the plan is less useful than it once was.
That assumes that the TAP parser has some degree of control over the TAP
emitter,
rf...@drivebuytech.com wrote:
> Late to this discussion. But can somebody explain to me why in java or .net
> or groovy or
> ruby a programmer doesn't have to induicate the number of tests that will
run before hand
> but in perl he must?
Let's make something clear, Perl says nothing about this.
David E. Wheeler wrote:
> On Jan 23, 2009, at 10:23 AM, Eric Wilhelm wrote:
>> I don't recall claiming that it was *simpler*. The single static
>> numeric plan is simplistic. Given any cross-platform skip issue or
>> optional-dependency condition, you have a situation where the plan
>> becomes ha
# from Fergal Daly
# on Friday 23 January 2009 14:20:
>You seem to be saying "calculating the checksum is tedious work for a
>human and should be done by a computer" but in that case all you are
>checking is that Test::Builder and Test::Harness agree on the tests
>they saw running.
No. That woul
2009/1/23 Eric Wilhelm :
> # from Fergal Daly
> # on Friday 23 January 2009 10:18:
>
>>sub test_foo {
>> increment_plan_by(3);
>> ok(foo(1), "foo1 test");
>> ok(foo(2), "foo2 test");
>> ok(foo(3), "foo3 test");
>>}
>>
>>but you forget add an actual test_foo() call or due to some bug, the
>>call
On Friday 23 January 2009 10:23:47 Eric Wilhelm wrote:
> Given any cross-platform skip issue or
> optional-dependency condition, you have a situation where the plan
> becomes harder for a human to get right. In that case, I want to
> program the test to react to the environment rather than shippi
On Jan 23, 2009, at 10:23 AM, Eric Wilhelm wrote:
I don't recall claiming that it was *simpler*. The single static
numeric plan is simplistic. Given any cross-platform skip issue or
optional-dependency condition, you have a situation where the plan
becomes harder for a human to get right. In
On Jan 23, 2009, at 10:18 AM, Fergal Daly wrote:
With nesting, you can move some aspects of the plan closer to the code
(which is good) but you must always have some part of the plan far
enough away from the code so that it is not subject to the same bugs.
Ideally something like this would work
# from Fergal Daly
# on Friday 23 January 2009 10:18:
>sub test_foo {
> increment_plan_by(3);
> ok(foo(1), "foo1 test");
> ok(foo(2), "foo2 test");
> ok(foo(3), "foo3 test");
>}
>
>but you forget add an actual test_foo() call or due to some bug, the
>call is skipped. Your tests will happily co
# from David E. Wheeler
# on Friday 23 January 2009 09:04:
>> my @resources = $manager->resources;
>> is_deeply([sort(@resources)], \...@expect_resources);
>>
>> Which fails more descriptively than a plan failure.
>
>Well there you've just solved your loop problem, haven't you? I think
>you've p
2009/1/23 Eric Wilhelm :
> # from Fergal Daly
> # on Friday 23 January 2009 02:07:
>
>>The point is that you want to declare your intention independently
>>from taking the action. If you declare the plan alongside performing
>>it, then your planning becomes subject to bugs.
>
> I'm sure that for ev
# from Fergal Daly
# on Friday 23 January 2009 02:07:
>The point is that you want to declare your intention independently
>from taking the action. If you declare the plan alongside performing
>it, then your planning becomes subject to bugs.
I'm sure that for every reason someone can cite about ne
On Jan 23, 2009, at 1:11 AM, Eric Wilhelm wrote:
If so, you're using the plan as something like a stand-in for the
assertion:
my @resources = $manager->resources;
is(scalar(@resources), 12, "have 12 resources");
And actually, you probably want to assert something like:
my @resources = $man
On Jan 22, 2009, at 11:22 PM, Ovid wrote:
Well, since the thread was about Eric's method of eliminating
'plan', after you made your explanation, I think it was clear that
the proposal would require, as Eric suggested, an alteration to core
TAP:
ok 1
ok 2
ok 1
ok 2
ok 3
Hi everybody,
On Jan 23, 2009, at 3:22 PM, Ovid wrote:
Well, since the thread was about Eric's method of eliminating
'plan', after you made your explanation, I think it was clear that
the proposal would require, as Eric suggested, an alteration to core
TAP:
ok 1
ok 2
ok 1
ok 2
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
2009/1/23 Eric Wilhelm :
> # from Ovid
> # on Thursday 22 January 2009 15:01:
>
>>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($reso
# from Ovid
# on Thursday 22 January 2009 15:01:
>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"; }
# 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
23 matches
Mail list logo
