On 2/8/06, Adam Kennedy <[EMAIL PROTECTED]> wrote: > 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).
A long time ago, I suggested (and implemented) the idea of nested test numbers. The idea being that your output looks like 1 # ok 2.1 # ok 2.2 # ok 2.3 # ok 3.1.1.1 # ok ... you get the idea the only rule would be that a.b.c.d must come before a.b.c.d+1 in the output. Each block can have a plan if you like then you just create a block for each process/thread that will emit test results. I've a feeling that Test::Harness would barf on the above output but if you prefix all the numbers with . then it's happy. Of course it would be good to have a version of TH that also undertands these nested test number properly, the . thing just lets you keep backward compatibility. So this solves the present problem and it also solves the problem of it being a pain to have a plan when you have data driven testing (#tests = #data x #tests per datum and other adjustments and don't forget those data that get an extra test etc etc). You can also put a group of tests into a subroutine and just plan for 1 test for each time the sub is called. Anyway, I hereby suggest it again but this time without an implementation. The last time, the biggest part of the implementation was rewiring Test::Builder to use a blessed ref rather than lexical variables for it's object attributes but now TB is like that by default, the rest shouldn't be too hard :) F
