On Wednesday 09 April 2008 02:08:18 Ovid wrote: > --- chromatic <[EMAIL PROTECTED]> wrote:
> > All* of the TAP I've ever seen has been transient data generated by > > one tool, processed by another tool, and almost immediately discarded. > All of the Java I've ever seen doesn't make use of first class > functions and therefore they're not very important. These are *generated* files. Are you in the practice of checking in generated files -- and not just files generated deliberately as part of a multi-stage compilation or deployment process, but files generated as a temporary byproduct of asking the question "Does the as it exists now work correctly right now?" Even in the few cases where you need to shuttle TAP documents back and forth, the plan is to include version information in the document, correct? Isn't the point of including a version so that TAP consumers will be able to consume the document correctly? > > Any organization which can't fix > > the handful of pieces which generate TAP-diag and the one or two > > pieces of > > code which consume TAP-diag in an afternoon is doing something wrong > > with > > regard to duplication and maintainability, and it'll take quite a few > > libations to make me believe that such organizations are actually > > testing their code in any rigorous sense. > > Really? Schwern threw in the towel and admitted that Test::Builder > isn't architecturally able to suit our needs. If Schwern admits this, > I suspect that it's not fair to attack organizations for not being able > to do in an afternoon what Schwern admits can't be effectively done. Both of our arguments presume the existence of an API for adding TAP diagnostics to a TAP stream. If the API is so difficult to use that organizations never emit any TAP diagnostics beyond those which Test::Builder emit by default, there's no problem. This is a red herring. If those organizations are able to emit custom TAP diagnostics, they should be able to change the code which calls this API. I recommend suggesting that people and organizations remove duplication from their test suites by factoring out identical code and testing patterns into testing modules -- just as we've done for several years now. -- c
