* Michael G Schwern [2011-10-29T05:20:07]
> [ What if subtests stop indenting? ]
Sorry, I'm quite late to the party.
I really like the isolated planning of subtests, and the visual indenting, and
(least of the three) the potential for building a better visualizer that works
with the subtest orga
Hiya,
On 30 Oct 2011, at 19:23, Michael G Schwern wrote:
[snip]
>> * How would a no_plan subtest merge into a planned stream?
>
> Just fine, thanks. It would require no work at all. Without the TAP
> formatting, a no_plan subtest is equivalent to just running some tests.
What I was thinking of
On 2011.10.30 11:15 PM, Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Sunday 30 October 2011 20:30:
>
>> The current Test::Builder implementation is a mess and its design
>> cannot go forward. They have to be gotten just right to ensure that
>> not just nested TAP is supported, but nestin
On Sun, Oct 30, 2011 at 11:30 PM, Michael G Schwern wrote:
> TB2 is the opposite of the second system syndrome. The second system is
> traditionally overbuilt with too many features that nobody needs. While the
> event system might qualify, the Test::Builder2 class itself does not.
I'm reservin
# from Michael G Schwern
# on Sunday 30 October 2011 20:30:
>The current Test::Builder implementation is a mess and its design
> cannot go forward. They have to be gotten just right to ensure that
> not just nested TAP is supported, but nesting in other formats. Or
> if those formats don't have
On 2011.10.30 7:21 PM, David Golden wrote:
> I haven't followed the T::B 2 work closely enough, so could I ask you
> to please step back and explain the benefits of T::B 1.5 that is worth
> stepping backwards in terms of capabilities? What I mean is that we
> have TAP::Harness now that processes s
On Sun, Oct 30, 2011 at 3:23 PM, Michael G Schwern wrote:
> On 2011.10.30 2:58 AM, Adrian Howard wrote:
>> I prefer the current subtests system for a few reasons:
>>
>> * With the new system I would have to re-write TAP streams from other sources
>> to match the numbering system of the current str
On 2011.10.30 2:58 AM, Adrian Howard wrote:
> I prefer the current subtests system for a few reasons:
>
> * With the new system I would have to re-write TAP streams from other sources
> to match the numbering system of the current stream. This makes more work for
> folk who are pulling in TAP stre
Hiya,
On 29 Oct 2011, at 10:20, Michael G Schwern wrote:
> On 2011.10.29 1:51 AM, Adrian Howard wrote:
>> On 29 Oct 2011, at 09:18, Michael G Schwern wrote:
>> [snip]
>>> Do you find *blocks with their own name and plan* convenient, or subtests
>>> which have their own separate test state (as cu
On 2011.10.29 3:51 AM, Fergal Daly wrote:
> It seems like it's impossible then to declare a global plan in advance
> if you use subtests unless you go counting all the sub tests which is
> no fun,
Yes, that's a very good point.
use Test::More tests => 3;
subtest "first" => sub { ... };
- http://blogs.perl.org/users/ovid/
> Twitter - http://twitter.com/OvidPerl/
>
>
> - Forwarded Message -
>> From: Ovid
>> To: Fergal Daly
>> Cc:
>> Sent: Saturday, 29 October 2011, 17:33
>> Subject: Re: Do we need subtests in
/OvidPerl/
- Forwarded Message -
> From: Ovid
> To: Fergal Daly
> Cc:
> Sent: Saturday, 29 October 2011, 17:33
> Subject: Re: Do we need subtests in TAP?
>
>>
>> From: Fergal Daly
>
>
>> It seems like it
On 29 October 2011 18:20, Michael G Schwern wrote:
> On 2011.10.29 1:51 AM, Adrian Howard wrote:
>> On 29 Oct 2011, at 09:18, Michael G Schwern wrote:
>> [snip]
>>> Do you find *blocks with their own name and plan* convenient, or subtests
>>> which have their own separate test state (as currently
On 2011.10.29 1:51 AM, Adrian Howard wrote:
> On 29 Oct 2011, at 09:18, Michael G Schwern wrote:
> [snip]
>> Do you find *blocks with their own name and plan* convenient, or subtests
>> which have their own separate test state (as currently implemented)
>
> This may be me being dim - but I'm not
Hey,
On 29 Oct 2011, at 09:18, Michael G Schwern wrote:
[snip]
> Do you find *blocks with their own name and plan* convenient, or subtests
> which have their own separate test state (as currently implemented)
This may be me being dim - but I'm not really groking the distinction you're
making. C
On 2011.10.28 6:52 AM, David Golden wrote:
> Without looking at the actual code, I would guess that the complexity
> is implementing subtests while preserving the legacy procedural
> interface that wraps calls to a global singleton.
No, that's not really the problem. It was when Ovid originally i
On 2011.10.28 12:23 AM, Ovid wrote:
> Echo chamber alert: I've often seen long discussions on this list ignore
> the "real world" (though often for good reason). In this case, it sounds
> like there's a consideration of removing a feature from TAP.
No, not removing from TAP but removing support fo
On Fri, Oct 28, 2011 at 3:23 AM, Ovid wrote:
> Moving along, the *idea* of a nested TAP is so conceptually simple that if
> the implementing code is struggling with it, perhaps it's a sign that there
> are some design decisions which should be revisited? When I find conceptually
> simple ideas
__
>From: Michael G Schwern
>To: Perl QA
>Sent: Wednesday, 26 October 2011, 23:09
>Subject: Re: Do we need subtests in TAP?
>
>Adrian forgot to send this to the list.
>
>
> Original Message
>Subject: Re: Do we need subtests in TAP?
>Date: Wed, 26 O
On 10/25/11 11:56 PM, Michael G Schwern wrote:
I keep looking at subtests and keeping thinking that if there wasn't a test
count to manage, would we need subtests? Do we need all that complexity? If
it's just about the test count, can it be managed a better way?
I haven't followed this discu
Adrian forgot to send this to the list.
Original Message
Subject: Re: Do we need subtests in TAP?
Date: Wed, 26 Oct 2011 14:14:31 +0100
From: Adrian Howard
To: Michael G Schwern
Hey there,
On 26 Oct 2011, at 04:56, Michael G Schwern wrote:
> I understand wanting "b
> "David" == David Golden writes:
David> I wonder how many people are using subtests with a plan and how many
David> are replying on the implied "done_testIng" feature.
I'm teaching it now, and I find it very valuable.
subtest 'network tests' => sub {
$ENV{NETWORK_TESTS} or
Hi,
On Wed, Oct 26, 2011 at 4:56 AM, Michael G Schwern wrote:
> I keep looking at subtests and keeping thinking that if there wasn't a test
> count to manage, would we need subtests? Do we need all that complexity? If
> it's just about the test count, can it be managed a better way?
>
> I under
On Tue, Oct 25, 2011 at 11:56 PM, Michael G Schwern wrote:
> I keep looking at subtests and keeping thinking that if there wasn't a test
> count to manage, would we need subtests? Do we need all that complexity? If
> it's just about the test count, can it be managed a better way?
I find several
I keep looking at subtests and keeping thinking that if there wasn't a test
count to manage, would we need subtests? Do we need all that complexity? If
it's just about the test count, can it be managed a better way?
I understand wanting "blocks of tests" and the ability to make plans for just
th
25 matches
Mail list logo
