two aspects of the framework that i consider deficiencies are: 1. the inability to run a *single* test within a script. 2. the lack of per-test descriptive text.
i realise the first is essentially insurmountable, given the structure, design, and implementation of the perl testing mechanism. (why would i want to? long-duration tests, or those that generate huge throbbing wads of error_log text in which the desired messages can easily be lost.) (you *can* run single scripts, as with 't/TEST t/modules/access.t', but that doesn't appear to be well documented [if at all].) the second one, however, is a significant pain in the arse, and there ought to be a solution (says i). as i mentioned before, i'm wrapping the suite up so a testing group can run it in a push-button fashion. but if their results come back saying 'test 43 of t/foo/bar failed', then it's not only meaningless to them, but very likely to a developer as well. afaik, the only ways to find out just what the hell happened is to run the test in verbose mode, and hope the test developer emitted some meaningful debugging text, or delve into the script itself to find out what test 43 is trying to do. that's just nasty. or am i missing something? one solution to this one would be to a) have guidelines about the test descriptions, such as ok($result eq $expected, "f(x): expected '$expected', got '$result'"); so that what was being attempted is clear; and b) retrofit all the scripts to be so descriptive. (whee!) i sincerely hope that i'm missing something basic, because the detail-digging is the only way i've found to be sure what happened. which is fine (though a pita) for developers, but *not* fine for others.. if i'm off-base, please be charitable -- i don't think i'm entirely awake yet. i'm certainly not trying to gore anyone's ox nor piss anyone off.. just frsutrated. -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
