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
