chromatic, > Any solution which requires a human being to read and think about the output > beyond "It's all okay!" or "Something fell!"* is not a long-term solution.
I don't think that's true of this implementation. If the script doesn't reach the all_done() call, there is a very obvious error. If it does, it internally produces a plan at the end--acceptable according to TAP specs--and it's very obviously okay. > In particular, you lose the separation between producing TAP and interpreting > TAP, as well as the automation benefits of both. I'm not sure I see what you're saying here. > The other function of a test plan is to make sure that you aren't running > *more* tests than you intended. If you don't know why that's important, try > patching File::Find sometime. I have. Well, that is admittedly a very real disadvantage of my method, and definitely one I hadn't considered. > Suppose you take advantage of the existence of Test::Builder and roll in > several other testing modules, per good programming practice of re-using > working and well-tested code. Whose responsibility is it then to emit the > single canonical all_done() call? The all_done() is handled by each individual test script. It should never be called in a library. Test::Aggregate might have to perform some magic to make sure it only gets called once, but my impression is that Test::Aggregate is already fairly magical. Thanx for taking the time to reply. -- Buddy