I'm in Prague all week, so I've been able to read, but not really participate.
Echo chamber alert: I've often seen long discussions on this list ignore the "real world" (though often for good reason). In this case, it sounds like there's a consideration of removing a feature from TAP. IMHO this is a bad idea which should be opened up to the community at large. Moving along, the *idea* of a nested TAP is so conceptually simple that if the implementing code is struggling with it, perhaps it's a sign that there are some design decisions which should be revisited? When I find conceptually simple ideas hard to do, I find it a code smell. (note that I'm not saying the actual design is bad. I haven't looked). I also find subtests so incredibly convenient and opens up so many possibilities that I would hate to lose them (and I use them a lot). Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/ >________________________________ >From: Michael G Schwern <schw...@pobox.com> >To: Perl QA <perl-qa@perl.org> >Sent: Wednesday, 26 October 2011, 23:09 >Subject: Re: Do we need subtests in TAP? > >Adrian forgot to send this to the list. > > >-------- Original Message -------- >Subject: Re: Do we need subtests in TAP? >Date: Wed, 26 Oct 2011 14:14:31 +0100 >From: Adrian Howard <adri...@quietstars.com> >To: Michael G Schwern <schw...@pobox.com> > >Hey there, > >On 26 Oct 2011, at 04:56, Michael G Schwern wrote: > >> I understand wanting "blocks of tests" and the ability to make plans for >> just those blocks, but do we need a discrete test state for that? For >> example, Test::Class provides most of what subtests provide without special >> support. > >... and to do that T::C contains a bunch of annoying special case code than is >(I think) still wrong in an odd corner case. Everybody who wants to do the >things T::C does will also have to do that work. > >T::C implemented with subtests is _much_ cleaner code. > >There may be other ways of getting that complexity out of T::C (and similar) >and into Test::Builder of course - but I'm not 100% sure what you're >suggesting... > >> It occurred to me because most other testing systems don't have subtests. >> They have test methods, but those aren't treated as a sub-state of the test. > >Some do have different levels of hierarchy though. (e.g. JUnit's Test Case / >Suite distinction). > >> In essence, a "subtest" is nothing more than a block of tests with a name >> and it's own plan. The special TAP formatting seems unnecessary. I guess >> that's the real question, do we need the special TAP formatting or do we >> just need named test blocks with their own plan? > >One thing subtests TAP formatting gives you is a simple way to nest TAP >streams from elsewhere. Any other system would mean you have to rewrite the >nested stream (I think?) > >Cheers, > >Adrian >-- >Who invented the eponym? > > >
