On Thursday, August 21, 2003, at 11:50 pm, Michael G Schwern wrote:
On Thu, Aug 21, 2003 at 10:19:35PM +0100, Fergal Daly wrote:
[snip]
Also you can allocate a sub block to each thread and you don't have
to worry
about it's output getting confused with the output of any other thread
because ever
On Thursday, August 21, 2003, at 08:17 pm, Michael G Schwern wrote:
On Thu, Aug 21, 2003 at 02:38:03PM +0100, Fergal Daly wrote:
[snip]
You could allow extensions at any time but then you lose the ability
to know
if you ran 4 + 2 tests or 5 + 1,
Not if you introduce an end tag (though I'd rather
On Thu, Aug 21, 2003 at 10:19:35PM +0100, Fergal Daly wrote:
> ok 1.2.3 allows this
>
> ok 1.1.1
> ok 1.2.1
> ok 1.1.2
> ok 1.2.2
>
> so if people use the Test::AtRuntime they can also execute those tests at test
> time, just allocate subblock 1.* to all the runtime tests. They will appear
> in
ok 1.2.3 allows this
ok 1.1.1
ok 1.2.1
ok 1.1.2
ok 1.2.2
so if people use the Test::AtRuntime they can also execute those tests at test
time, just allocate subblock 1.* to all the runtime tests. They will appear
in the output, intermixed with all your other tests but they will not
interfere wi
On Thu, Aug 21, 2003 at 12:17:39PM -0700, Michael G Schwern wrote:
> Not if you introduce an end tag (though I'd rather not).
Why not? I'd like the ability to specify a variant of no plan that is
roughly "it ain't over until the fat lady sings" and then if I don't
print out a singing fat lady as
On Thu, Aug 21, 2003 at 02:39:56PM +0100, Fergal Daly wrote:
> Full nesting requires more state to be held and as it stands, doesn't help in
> your example below. It could be altered to support it though by adding
> support for standalone sub blocks, ie where the harness should temporarily
> for
On Thu, Aug 21, 2003 at 02:38:03PM +0100, Fergal Daly wrote:
> 1 problem here is that you have not indicated anywhere how many times you will
> be extending the plan
Some sort of *optional* way to specify that would be nice.
> > The former has the large disadvange of requiring all subtests to b
On Wednesday 20 August 2003 22:19, Michael G Schwern wrote:
> That's subtests having overall test state. Ideally don't want the subtests
> to have *any* awareness that they're being run as a subtest.
The state is held in the Test::Builder object just as currently, it's just
that that object has
On Wednesday 20 August 2003 22:14, Michael G Schwern wrote:
> 1..2
> ok 1
> 1..3
> ok 1
> ok 2
> ok 3
> 3..1
> ok 2
1 problem here is that you have not indicated anywhere how many times you will
be extending the plan so maybe there's a
1..9
ok 1
...
ok 9
missing off the end, there's no way to
On Wednesday 20 August 2003 08:23, Michael G Schwern wrote:
> You don't want subtests to have to know any state, such as how far to
> indent. Why? Consider:
Something has to keep state, I was assuming it would be the block. Anyway, the
indentation thing is bad because it won't work for threaded
On Wednesday 20 August 2003 11:52, Michael G Schwern wrote:
> I've yet to see a real use-case for plans of plans.
Currently it's impossible to use testing functions and plans without major
headaches. If I do this
sub is_valid_person
{
my $person = shift;
like($person->{Name}, "(
On Wed, Aug 20, 2003 at 02:06:04PM +0100, Fergal Daly wrote:
> > Work under the assumption that each subplan is not aware of the state
> > of the overall test. This will produce the most useful protocol.
>
> In the scheme mentioned, the only thing the sub-plan is aware of is it's
> name/number,
On Wed, Aug 20, 2003 at 02:00:28PM +0100, Adrian Howard wrote:
> On Wednesday, August 20, 2003, at 11:52 am, Michael G Schwern wrote:
> [snip]
> >I've yet to see a real use-case for plans of plans.
> [snip]
>
> Anywhere when you want to have plans at a higher level of granularity
> than a test s
On Wed, Aug 20, 2003 at 03:52:42AM -0700, Michael G Schwern wrote:
> On Wed, Aug 20, 2003 at 10:34:08AM +0100, Fergal Daly wrote:
> > On Wednesday 20 August 2003 08:23, Michael G Schwern wrote:
> > > You don't want subtests to have to know any state, such as how far to
> > > indent. Why? Consider:
On Wednesday, August 20, 2003, at 11:52 am, Michael G Schwern wrote:
[snip]
I've yet to see a real use-case for plans of plans.
[snip]
Anywhere when you want to have plans at a higher level of granularity
than a test script.
For example in Test::Class I can say:
sub pig_flying : Test(2) {
On Wed, Aug 20, 2003 at 10:34:08AM +0100, Fergal Daly wrote:
> On Wednesday 20 August 2003 08:23, Michael G Schwern wrote:
> > You don't want subtests to have to know any state, such as how far to
> > indent. Why? Consider:
>
> Something has to keep state
The state of the overall test? No, that
On Wed, Jun 25, 2003 at 02:25:11PM +0100, Fergal Daly wrote:
> I just wanted to bring up nested blocks and sub-plans again. I've been hacking
> around in Test::Builder and I've implemented something that works and does
> something that I think is useful. It allows you to write tests that have
>
I could throw up a Wiki somewhere if people think it would be useful
(I've been looking for an excuse to play with CGI::Kwiki).
(IRC is to scary a time sink for me ;-)
Adrian
On Wednesday, June 25, 2003, at 07:14 pm, Fergal Daly wrote:
On Wednesday 25 June 2003 17:56, Andy Lester wrote:
This
On Wednesday 25 June 2003 17:56, Andy Lester wrote:
> This is something Schwern and I have discussed before, and that I
> would LOVE to put into Test::Harness, if only we could hash out the
> specifics. Are you ever in AIM/IRC? I'd kinda like to have an
> online workgroup to thrash on the spec
Why would you want to do this? Simple example.
This is something Schwern and I have discussed before, and that I
would LOVE to put into Test::Harness, if only we could hash out the
specifics. Are you ever in AIM/IRC? I'd kinda like to have an
online workgroup to thrash on the specifics...
xoa
20 matches
Mail list logo
