Re: User Supplied YAML Diagnostic Keys
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
Re: Preparing a new Test::* module
Hi!
On Wed, Apr 09, 2008 at 02:49:05PM +0100, Fergal Daly wrote:
> On 09/04/2008, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> > On Mon, Apr 7, 2008 at 10:14 PM, Fergal Daly <[EMAIL PROTECTED]> wrote:
> > > I would say put as much as possible of this outside the Test::
> > > namespace and then wrap in a thin Test:: wrapper. I wish I'd done this
> > > with Test::Deep, it's on the todo list but I'll never get around to
> > > it,
> >
> >
> > I am not sure how it will work out, but maybe add it to the TODO Tracker
> > http://todo.useperl.at/ so someone will pick it up and do it for money.
> > I'd really like to see that separated.
>
> Since I'm not willing to pay for it, feel free to add it yourself :)
No,no, Vienna.pm will pay for it. We just need project maintainers to
a) submit things they want to be done (including a price tag) and b)
review the work done by implementors.
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
Re: Preparing a new Test::* module
On 09/04/2008, Gabor Szabo <[EMAIL PROTECTED]> wrote: > On Mon, Apr 7, 2008 at 10:14 PM, Fergal Daly <[EMAIL PROTECTED]> wrote: > > I would say put as much as possible of this outside the Test:: > > namespace and then wrap in a thin Test:: wrapper. I wish I'd done this > > with Test::Deep, it's on the todo list but I'll never get around to > > it, > > > I am not sure how it will work out, but maybe add it to the TODO Tracker > http://todo.useperl.at/ so someone will pick it up and do it for money. > I'd really like to see that separated. Since I'm not willing to pay for it, feel free to add it yourself :) (if it requires the author to do it, let me know and I will). Another option is to give the illusion of good design and create a non-Test module which presents only the non-Test interfaces of Test::Deep with a dependency on Test::Deep. I'd support anyone's attempt to do that, F > Gabor >
Re: Preparing a new Test::* module
On Mon, Apr 7, 2008 at 10:14 PM, Fergal Daly <[EMAIL PROTECTED]> wrote: > I would say put as much as possible of this outside the Test:: > namespace and then wrap in a thin Test:: wrapper. I wish I'd done this > with Test::Deep, it's on the todo list but I'll never get around to > it, I am not sure how it will work out, but maybe add it to the TODO Tracker http://todo.useperl.at/ so someone will pick it up and do it for money. I'd really like to see that separated. Gabor
Re: Preparing a new Test::* module
--- "Randy J. Ray" <[EMAIL PROTECTED]> wrote: > > Test::Text::Format (generic interface) > > Test::Text::Format::XML > > Test::Text::Format::YAML > > Test::Text::Format::Etcetera > > > > Feels a bit clumsy. I tend to dislike starting out three levels deep > unless > the middle level already exists, and there's no "Test::Text" > currently. It does feel clumsy, but it does seem to reflect what is going on. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
Re: User Supplied YAML Diagnostic Keys
--- 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. > 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. Unless you're suggesting they throw all of this away and write bespoke testing tools which don't play with what is already on the CPAN? I really can't tell from what you've written. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
