Geoffrey Young wrote:
hi all :)
there's a feature split I'm itching for in Test::Builder, etc - the
ability to call is() and have it emit TAP free from the confines of
plan(). not that I don't want to call plan() (or no_plan) but I want to
do that in a completely separate perl interpreter. for example, I want
to do something that looks a bit like this
use Test::More tests => 1;
print qx!perl t/response.pl!;
where response.pl makes a series of calls to is(), ok(), whatever.
while this may seem odd it's actually not - I'd like to be able to
plan() tests within a client *.t script but have the responses come from
one (or more) requests to any kind of server (httpd, smtp, whatever).
currently in httpd land we can do this by calling plan() and is() from
within a single server-side perl script, but the limitation there is
that you can only do that once - if I want to test, say, keepalives I
can't have a single test script make multiple requests each with their
own plan() calls without things getting tripped up.
so, I guess my question is whether the plan->is linkage can be broken in
Test::Builder/Test::Harness/wherever and still keep the bookkeeping in
tact so that the library behaves the same way for the bulk case. or
maybe at least provide some option where calls to is() don't bork out
because there's no plan (and providing an option to Test::More where it
doesn't send a plan header).
so, thoughts or ideas? am I making any sense?
--Geoff
One of the problems is going to be numbering, surely?
I've just started myself mucking around with some ideas where I wanted
to fork off a server process and then test in BOTH halves of a
connection at the same time. It sounds like something relatively similar
to what you need to do.
One of the things I didn't really like about generating fragments is you
don't really get a chance to count each set, only the total (or worse,
no plans at all).
What I think might be a useful approach is being able to "merge"
fragments to test output.
So the lines from the external fragment would be parsed in, checked (in
plan terms) and then re-emitted into the main test (which would have a
plan totallying the whole group).
Adam K
