From mpeters at plusthree.com Sat Apr 7 16:10:24 2007 From: mpeters at plusthree.com (Michael Peters) Date: Sat, 07 Apr 2007 11:10:24 -0400 Subject: [tap-l] multi-file TAP In-Reply-To: <875029960704061711q2f4abbbbq39ee740f5c5359e8@mail.gmail.com> References: <4616B758.9040400@plusthree.com> <20070406221750.GR22282@klangraum> <5C3949FA-7606-4865-928C-16D0C2CFE915@hexten.net> <875029960704061711q2f4abbbbq39ee740f5c5359e8@mail.gmail.com> Message-ID: <4617B460.4090001@plusthree.com> Bringing this over from Perl-QA: Fergal Daly wrote: > On 07/04/07, Andy Armstrong wrote: >> On 6 Apr 2007, at 23:17, A. Pagaltzis wrote: >> >> > * Michael Peters [2007-04-06 23:15]: >> >> Maybe I'm missing something (and if so, please point out the >> >> obvious to me) but I can't find a way for a single TAP file to >> >> contain results from multiple test files. >> > >> > There isn't one. There was recently discussion about this, with >> > mixed opinions about whether it's needed and what it might look >> > like. One of the suggestions was that it has overlap with the >> > grouping/nesting proposals that keep re-appearing. >> >> It's definitely a valuable idea and it's entirely consistent with the >> notion that TAP is a streaming protocol. We should be able to stream >> a complete test run without any out-of-band communication about where >> one file stops and another starts. >> >> The overlap with the grouping/nesting proposals is that once you can >> split a TAP stream into top level chunks why not allow nested chunks? >> I like that idea too. It means that you can always wrap a TAP stream >> in BEGIN/END [1] even if it's already chunked. >> >> [1] Or whatever. > > To address the whatever, BEGIN/END draws you into the XMLish problems > of waiting for a complete document before acting on the contents and > even if you avoid this it still makes it hard to interleave streams. > > I'm starting to think that every line should be prefixed by a test > number, including diags (diags are not currently associated with a > particular test but could be made so) so something like > > 1.2.3 not ok blah > 1.2.3 # got: 4 > 1.2.3 # not: 3 > 1.2.3 end I think this has problems for identifying which test file it came from. For one, there is no mention of which file is being processed. But the biggest problem is that in order for a file (or stream) to know which number it is, the harness needs to let it know (passing some environment var to Test::Builder?). This means the harness tells the test file which prefix to use just so that the harness can then group them properly. Seems backwards. The TAP producers shouldn't care about the bookkeeping that the TAP harness needs. Now I'm not saying that nested groups wouldn't be nice, but used within a single file/stream, not mixing between them. Here are my simple thoughts on the matter (and you can substitute "file" for "stream"): + A single test file can be run and output valid TAP and be considered a full test run. + Multiple test files can be run in whatever sequence the harness wants and there should be a way for the harness to join those results together into a single valid TAP file so that the entire test run can be captured. + Joining the results of multiple files is the job of the harness, not the individual test files, so the behavior of the individual files should not be altered whether they are being run by themselves, or with others. In my opinion it would be nice if TAP::Harness would act as both a consumer and producer of TAP with the option of joining the individual TAP streams into a single file that can then be consumed by something else downstream. If things get really complicated with multiple streams running at the same time, then it's up to the harness to do the coordinating. I agree with Andy Armstrong in the other part of this thread where he said to just give each stream it's own TAP::Parser and then coordinate the results when they're done. And with regard to BEGIN/END blocks, I don't think we need an END, just a BEGIN since we can treat it like Perl's "package" and just assume one file until we see another. -- Michael Peters Developer Plus Three, LP From andy at hexten.net Sat Apr 7 16:58:47 2007 From: andy at hexten.net (Andy Armstrong) Date: Sat, 7 Apr 2007 16:58:47 +0100 Subject: [tap-l] multi-file TAP In-Reply-To: <4617B460.4090001@plusthree.com> References: <4616B758.9040400@plusthree.com> <20070406221750.GR22282@klangraum> <5C3949FA-7606-4865-928C-16D0C2CFE915@hexten.net> <875029960704061711q2f4abbbbq39ee740f5c5359e8@mail.gmail.com> <4617B460.4090001@plusthree.com> Message-ID: <23948B0D-EF9E-422B-A9D0-46C24598936C@hexten.net> On 7 Apr 2007, at 16:10, Michael Peters wrote: > + A single test file can be run and output valid TAP and be > considered a full > test run. > + Multiple test files can be run in whatever sequence the harness > wants and > there should be a way for the harness to join those results > together into a > single valid TAP file so that the entire test run can be captured. > + Joining the results of multiple files is the job of the harness, > not the > individual test files, so the behavior of the individual files > should not be > altered whether they are being run by themselves, or with others. Yes. Absolutely. I propose begin end where includes begin and end. For the purposes of the plan a begin, , end sequence is a single test - so each begin / end block also needs a plan. plan 3 begin "Spigot extraction" plan 3 ok 1 Spigot::Extractor loaded ok 2 Spigot visble not ok 3 Spigot free end begin "Documentation" plan 1 ok 1 Documentation makes sense end ok 3 All tests completed I'm not sure whether begin / end blocks could also carry a test number since they're semantically equivalent to single tests from the PoV of the containing TAP. > In my opinion it would be nice if TAP::Harness would act as both a > consumer and > producer of TAP with the option of joining the individual TAP > streams into a > single file that can then be consumed by something else downstream. TAP::Pipes :) Yes, I like that. > If things > get really complicated with multiple streams running at the same > time, then it's > up to the harness to do the coordinating. I agree with Andy > Armstrong in the > other part of this thread where he said to just give each stream > it's own > TAP::Parser and then coordinate the results when they're done. > > And with regard to BEGIN/END blocks, I don't think we need an END, > just a BEGIN > since we can treat it like Perl's "package" and just assume one > file until we > see another. You need END *if* you're going to allow blocks to nest. Of course we haven't decided that they should nest but it seems desirable to me that they should. If you run 100,000 tests and just glue them together end to end then you can't, for example, build a web based interface that lets you drill down to the results you're interested in. The more test output people produce with TAP the more they're going to appreciate working with a hierarchy of test results rather than just a linear list. Fergal anticipated that nesting would give us the same problems you get with XML where you can't process a node until you've seen it all. That's true for XML in general because many grammars aren't strict about the ordering of elements - so you might have to parse the whole document to get to the title which just happens to be at the end. We don't have that problem - TAP output is strictly ordered (admittedly apart from the trailing plan special case). -- Andy Armstrong, hexten.net From publiustemp-tapx at yahoo.com Sat Apr 7 20:18:02 2007 From: publiustemp-tapx at yahoo.com (Ovid) Date: Sat, 7 Apr 2007 12:18:02 -0700 (PDT) Subject: [tap-l] multi-file TAP In-Reply-To: <23948B0D-EF9E-422B-A9D0-46C24598936C@hexten.net> Message-ID: <960473.29574.qm@web60819.mail.yahoo.com> --- Andy Armstrong wrote: > plan 3 > begin "Spigot extraction" > plan 3 > ok 1 Spigot::Extractor loaded > ok 2 Spigot visble > not ok 3 Spigot free > end > begin "Documentation" > plan 1 > ok 1 Documentation makes sense > end > ok 3 All tests completed 1. Your leading "plan 3" only had two begin/end sets. 2. I'd feel more comfortable if the "end" block also carried the description. 3. Infinite TAP streams are allowed. Infinite test files possibly should be allowed, also. > > And with regard to BEGIN/END blocks, I don't think we need an END, > > just a BEGIN > > since we can treat it like Perl's "package" and just assume one > > file until we > > see another. There are non-perl folk on this list. They might not know what BEGIN/END blocks are. In any event, I'd still prefer to specify behavior rather than implementation. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/ From scratchcomputing at gmail.com Sat Apr 7 21:01:25 2007 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Sat, 7 Apr 2007 13:01:25 -0700 Subject: [tap-l] multi-file TAP In-Reply-To: <23948B0D-EF9E-422B-A9D0-46C24598936C@hexten.net> References: <4616B758.9040400@plusthree.com> <4617B460.4090001@plusthree.com> <23948B0D-EF9E-422B-A9D0-46C24598936C@hexten.net> Message-ID: <200704071301.25509.ewilhelm@cpan.org> # from Andy Armstrong # on Saturday 07 April 2007 08:58 am: >plan 4 >begin "Spigot extraction" >? ?plan 3 >? ?ok 1 Spigot::Extractor loaded >? ?ok 2 Spigot visble >? ?not ok 3 Spigot free >end >begin "Documentation" >? ?plan 1 >? ?ok 1 Documentation makes sense >end >ok 3 All tests completed Doesn't that last line invalidate the 'plan 4' bit? If we're indenting, couldn't we do without the 'end'? Even without indenting, I'm a bit wary of a begin/end scheme simply because it allows results and files the same status. It's like a data structure of: - value - [list of values] - value - [list of values [list of values] value] - value It seems it would make more sense as: - [list of values] - [[lists of lists], [of values]] Or at least, not allowing trailing and interspersed bits: - value - value - - list - of - values - - value - value - - list - of - values Maybe I'm just suffering the xml jitters. Even the above scares me. It's like we're going to build a data structure using only the tag . What about a directory/file concept? Directories have no values, they are just containers. container top begin foo ok 1 container category1 begin bar ok 1 container category1.1 begin baz ok 1 begin bat ok 1 container category2 begin foo ok 1 Or so, representing this tree top/ |-- category1 | |-- bar | `-- category1.1 | |-- bat | `-- baz |-- category2 | `-- foo `-- foo There's nothing in that which says a test file can't pretend to be a directory, only that it can't simultaneously be a file and a directory. The flat directory would then be: begin foo ok 1 begin bar ok 1 Where the root container is implied, just as begin is implied for a single file. --Eric -- If the collapse of the Berlin Wall had taught us anything, it was that socialism alone was not a sustainable economic model. --Robert Young --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From andy at hexten.net Sat Apr 7 21:15:47 2007 From: andy at hexten.net (Andy Armstrong) Date: Sat, 7 Apr 2007 21:15:47 +0100 Subject: [tap-l] multi-file TAP In-Reply-To: <960473.29574.qm@web60819.mail.yahoo.com> References: <960473.29574.qm@web60819.mail.yahoo.com> Message-ID: On 7 Apr 2007, at 20:18, Ovid wrote: > --- Andy Armstrong wrote: >> plan 3 >> begin "Spigot extraction" >> plan 3 >> ok 1 Spigot::Extractor loaded >> ok 2 Spigot visble >> not ok 3 Spigot free >> end >> begin "Documentation" >> plan 1 >> ok 1 Documentation makes sense >> end >> ok 3 All tests completed > > 1. Your leading "plan 3" only had two begin/end sets. And one top level test result for a total of three. > 2. I'd feel more comfortable if the "end" block also carried the > description. Yup, makes sense. > 3. Infinite TAP streams are allowed. Infinite test files possibly > should be allowed, also. I think that's still OK, no? >>> And with regard to BEGIN/END blocks, I don't think we need an END, > >>> just a BEGIN >>> since we can treat it like Perl's "package" and just assume one >>> file until we >>> see another. > > There are non-perl folk on this list. They might not know what > BEGIN/END blocks are. In any event, I'd still prefer to specify > behavior rather than implementation. More to the point they might not know what 'package' is. The BEGIN/ END being discussed here != Perl's BEGIN/END. -- Andy Armstrong, hexten.net From andy at hexten.net Sat Apr 7 21:29:24 2007 From: andy at hexten.net (Andy Armstrong) Date: Sat, 7 Apr 2007 21:29:24 +0100 Subject: [tap-l] multi-file TAP In-Reply-To: <200704071301.25509.ewilhelm@cpan.org> References: <4616B758.9040400@plusthree.com> <4617B460.4090001@plusthree.com> <23948B0D-EF9E-422B-A9D0-46C24598936C@hexten.net> <200704071301.25509.ewilhelm@cpan.org> Message-ID: <6BD2BC2C-F026-4018-9684-301451E26FF9@hexten.net> On 7 Apr 2007, at 21:01, Eric Wilhelm wrote: > # from Andy Armstrong > # on Saturday 07 April 2007 08:58 am: > >> plan 4 >> begin "Spigot extraction" >> plan 3 >> ok 1 Spigot::Extractor loaded >> ok 2 Spigot visble >> not ok 3 Spigot free >> end >> begin "Documentation" >> plan 1 >> ok 1 Documentation makes sense >> end >> ok 3 All tests completed > > Doesn't that last line invalidate the 'plan 4' bit? It should be plan 3 - two begin/end pairs and a naked test. > If we're indenting, couldn't we do without the 'end'? I'm only indenting for clarity. I suppose that - for even more clarity - I could have mentioned that :) > Even without indenting, I'm a bit wary of a begin/end scheme simply > because it allows results and files the same status. It's like a data > structure of: [snip] > Maybe I'm just suffering the xml jitters. Even the above scares me. > It's like we're going to build a data structure using only the tag > . Well programming languages manage OK with only a single tag, often called '{': statement ::= simple-statement | '{' simple-statement * '}' Here's a problem: how to we handle TAP version? You'd want the TAP version at the front of a TAP stream to reflect the version of everything the stream contains - but if you're merging multiple streams you haven't necessarily seen them yet to know what version they are. -- Andy Armstrong, hexten.net From fergal at esatclear.ie Sat Apr 7 23:51:18 2007 From: fergal at esatclear.ie (Fergal Daly) Date: Sat, 7 Apr 2007 23:51:18 +0100 Subject: [tap-l] multi-file TAP In-Reply-To: <4617B460.4090001@plusthree.com> References: <4616B758.9040400@plusthree.com> <20070406221750.GR22282@klangraum> <5C3949FA-7606-4865-928C-16D0C2CFE915@hexten.net> <875029960704061711q2f4abbbbq39ee740f5c5359e8@mail.gmail.com> <4617B460.4090001@plusthree.com> Message-ID: <875029960704071551k28015ec0h5ee9d30c97eb315f@mail.gmail.com> On 07/04/07, Michael Peters wrote: > Bringing this over from Perl-QA: > > Fergal Daly wrote: > > On 07/04/07, Andy Armstrong wrote: > > To address the whatever, BEGIN/END draws you into the XMLish problems > > of waiting for a complete document before acting on the contents and > > even if you avoid this it still makes it hard to interleave streams. > > > > I'm starting to think that every line should be prefixed by a test > > number, including diags (diags are not currently associated with a > > particular test but could be made so) so something like > > > > 1.2.3 not ok blah > > 1.2.3 # got: 4 > > 1.2.3 # not: 3 > > 1.2.3 end > > I think this has problems for identifying which test file it came from. For one, > there is no mention of which file is being processed. That's because I've omitted most of the output. Each block has a name (just like each test has a name) embed the script name in there or for threads/forks give them a sensible name related to what the fork is doing. > But the biggest problem is > that in order for a file (or stream) to know which number it is, the harness > needs to let it know (passing some environment var to Test::Builder?). This > means the harness tells the test file which prefix to use just so that the > harness can then group them properly. Seems backwards. The TAP producers > shouldn't care about the bookkeeping that the TAP harness needs. If you have multiple scripts being fired up by a harness, the harness can blockifies the output of each one. The script doesn't need to know anything about the block inside which it runs. Just like the harness is what adds the BEGIN/END lines and indentation in the other proposal. F > Now I'm not saying that nested groups wouldn't be nice, but used within a single > file/stream, not mixing between them. > > Here are my simple thoughts on the matter (and you can substitute "file" for > "stream"): > > + A single test file can be run and output valid TAP and be considered a full > test run. > + Multiple test files can be run in whatever sequence the harness wants and > there should be a way for the harness to join those results together into a > single valid TAP file so that the entire test run can be captured. > + Joining the results of multiple files is the job of the harness, not the > individual test files, so the behavior of the individual files should not be > altered whether they are being run by themselves, or with others. > > In my opinion it would be nice if TAP::Harness would act as both a consumer and > producer of TAP with the option of joining the individual TAP streams into a > single file that can then be consumed by something else downstream. If things > get really complicated with multiple streams running at the same time, then it's > up to the harness to do the coordinating. I agree with Andy Armstrong in the > other part of this thread where he said to just give each stream it's own > TAP::Parser and then coordinate the results when they're done. > > And with regard to BEGIN/END blocks, I don't think we need an END, just a BEGIN > since we can treat it like Perl's "package" and just assume one file until we > see another. > > -- > Michael Peters > Developer > Plus Three, LP > > From publiustemp-tapx at yahoo.com Sun Apr 8 10:37:07 2007 From: publiustemp-tapx at yahoo.com (Ovid) Date: Sun, 8 Apr 2007 02:37:07 -0700 (PDT) Subject: [tap-l] multi-file TAP In-Reply-To: <6BD2BC2C-F026-4018-9684-301451E26FF9@hexten.net> Message-ID: <705553.80237.qm@web60818.mail.yahoo.com> --- Andy Armstrong wrote: > >> plan 4 > >> begin "Spigot extraction" > >> plan 3 > >> ok 1 Spigot::Extractor loaded > >> ok 2 Spigot visble > >> not ok 3 Spigot free > >> end > >> begin "Documentation" > >> plan 1 > >> ok 1 Documentation makes sense > >> end > >> ok 3 All tests completed > > > > Doesn't that last line invalidate the 'plan 4' bit? > > It should be plan 3 - two begin/end pairs and a naked test. Also, we should not overload the meaning of 'plan'. Keep the parsers simple by having 'plan' mean one thing and one thing only. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/ From andy at hexten.net Sun Apr 8 11:26:03 2007 From: andy at hexten.net (Andy Armstrong) Date: Sun, 8 Apr 2007 11:26:03 +0100 Subject: [tap-l] multi-file TAP In-Reply-To: <705553.80237.qm@web60818.mail.yahoo.com> References: <705553.80237.qm@web60818.mail.yahoo.com> Message-ID: On 8 Apr 2007, at 10:37, Ovid wrote: >> It should be plan 3 - two begin/end pairs and a naked test. > > Also, we should not overload the meaning of 'plan'. Keep the parsers > simple by having 'plan' mean one thing and one thing only. Indeed - that was me trying to TAP while doing something entirely different and getting confused about what TAP actually looks like :) I /think/ it's right on this page: http://testanything.org/wiki/index.php/Test_Blocks TAP version 14 1..4 begin 1 Object creation 1..2 ok 1 Object created OK ok 2 Object isa Flunge::Twizzler end 1 Object creation ok 2 Clone OK begin 3 Methods 1..4 ok 1 has twizzle method ok 2 has burnish method ok 3 has spangle method not ok 4 has frob method end 3 Methods ok 4 Resources released -- Andy Armstrong, hexten.net From andy at hexten.net Thu Apr 12 13:09:41 2007 From: andy at hexten.net (Andy Armstrong) Date: Thu, 12 Apr 2007 13:09:41 +0100 Subject: [tap-l] Testing in PHP / Message-ID: <226B1483-9BA5-4BCE-ACBA-C0E9888F2A6D@hexten.net> I know how to run my tests with Perl but what do people's testing setups look like for other languages? Right now I'm interested in PHP specifically. I've started a page on the Wiki where we can collect testing practices per language. I'd be particularly grateful if anyone could write the PHP page :) http://testanything.org/wiki/index.php/Testing_with_TAP -- Andy Armstrong, hexten.net From geoff at modperlcookbook.org Thu Apr 12 14:25:31 2007 From: geoff at modperlcookbook.org (Geoffrey Young) Date: Thu, 12 Apr 2007 09:25:31 -0400 Subject: [tap-l] Testing in PHP / In-Reply-To: <226B1483-9BA5-4BCE-ACBA-C0E9888F2A6D@hexten.net> References: <226B1483-9BA5-4BCE-ACBA-C0E9888F2A6D@hexten.net> Message-ID: <461E334B.7050304@modperlcookbook.org> Andy Armstrong wrote: > I know how to run my tests with Perl but what do people's testing > setups look like for other languages? Right now I'm interested in PHP > specifically. > > I've started a page on the Wiki where we can collect testing > practices per language. I'd be particularly grateful if anyone could > write the PHP page :) > > http://testanything.org/wiki/index.php/Testing_with_TAP > chris and I have actually done quite a bit of work in this area, to the point where many of the populat php testing tools now emit TAP. http://search.cpan.org/~petdance/Test-Harness-2.64/lib/Test/Harness/TAP.pod#PHP of course, I'm biased toward the Apache-Test solution and libraries, but it shouldn't be the case that you need to roll your own solution anymore. HTH --Geoff From geoff at modperlcookbook.org Thu Apr 12 14:27:43 2007 From: geoff at modperlcookbook.org (Geoffrey Young) Date: Thu, 12 Apr 2007 09:27:43 -0400 Subject: [tap-l] Testing in PHP / In-Reply-To: <461E334B.7050304@modperlcookbook.org> References: <226B1483-9BA5-4BCE-ACBA-C0E9888F2A6D@hexten.net> <461E334B.7050304@modperlcookbook.org> Message-ID: <461E33CF.10606@modperlcookbook.org> Geoffrey Young wrote: > Andy Armstrong wrote: > >>I know how to run my tests with Perl but what do people's testing >>setups look like for other languages? Right now I'm interested in PHP >>specifically. >> >>I've started a page on the Wiki where we can collect testing >>practices per language. I'd be particularly grateful if anyone could >>write the PHP page :) >> >>http://testanything.org/wiki/index.php/Testing_with_TAP >> > > > chris and I have actually done quite a bit of work in this area, to the > point where many of the populat php testing tools now emit TAP. > > http://search.cpan.org/~petdance/Test-Harness-2.64/lib/Test/Harness/TAP.pod#PHP > > of course, I'm biased toward the Apache-Test solution and libraries, but > it shouldn't be the case that you need to roll your own solution anymore. I should mention that we've also presented TAP-based PHP testing at both ApacheCon and OSCon (and Chris at various PHP events). the talks we did together can be found here http://www.modperlcookbook.org/~geoff/ and I'm sure Chris can give you a link to the ones he's done solo. --Geoff From andy at hexten.net Thu Apr 12 14:33:50 2007 From: andy at hexten.net (Andy Armstrong) Date: Thu, 12 Apr 2007 14:33:50 +0100 Subject: [tap-l] Testing in PHP / In-Reply-To: <461E33CF.10606@modperlcookbook.org> References: <226B1483-9BA5-4BCE-ACBA-C0E9888F2A6D@hexten.net> <461E334B.7050304@modperlcookbook.org> <461E33CF.10606@modperlcookbook.org> Message-ID: On 12 Apr 2007, at 14:27, Geoffrey Young wrote: > I should mention that we've also presented TAP-based PHP testing at > both > ApacheCon and OSCon (and Chris at various PHP events). the talks > we did > together can be found here [snip] I've added those as links: http://testanything.org/wiki/index.php/Testing_with_PHP I guess what I have in mind is for (insert name of volunteer here) to write HOWTOs for TAP testing in each language. Specific guidelines for how to set up a TAP based testing environment. -- Andy Armstrong, hexten.net From andy at hexten.net Thu Apr 12 14:53:27 2007 From: andy at hexten.net (Andy Armstrong) Date: Thu, 12 Apr 2007 14:53:27 +0100 Subject: [tap-l] Testing in PHP / In-Reply-To: References: <226B1483-9BA5-4BCE-ACBA-C0E9888F2A6D@hexten.net> <461E334B.7050304@modperlcookbook.org> <461E33CF.10606@modperlcookbook.org> Message-ID: <83A31061-F224-4D89-95E6-6994684C2855@hexten.net> On 12 Apr 2007, at 14:33, Andy Armstrong wrote: > I've added those as links: > http://testanything.org/wiki/index.php/Testing_with_PHP > > I guess what I have in mind is for (insert name of volunteer here) to > write HOWTOs for TAP testing in each language. Specific guidelines > for how to set up a TAP based testing environment. Or if such a HOWTO already exists put a link to it there :) -- Andy Armstrong, hexten.net From publiustemp-tapx at yahoo.com Sun Apr 22 14:32:13 2007 From: publiustemp-tapx at yahoo.com (Ovid) Date: Sun, 22 Apr 2007 06:32:13 -0700 (PDT) Subject: [tap-l] XML Versus TAP Message-ID: <380436.67375.qm@web60824.mail.yahoo.com> If anyone's interested, I did a small writeup of XML versus TAP on my O'Reilly blog: http://www.oreillynet.com/onlamp/blog/2007/04/xml_versus_tap.html http://tinyurl.com/2mhrog Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/ From patrick.leboutillier at gmail.com Wed Apr 25 15:19:05 2007 From: patrick.leboutillier at gmail.com (Patrick LeBoutillier) Date: Wed, 25 Apr 2007 10:19:05 -0400 Subject: [tap-l] Tap for Java Message-ID: Hi all, I while back I ported libtap to Java. The code can be found here (the are no docs however but usage is similar to libtap): http://svn.solucorp.qc.ca/repos/solucorp/JTap/trunk/ Basically all you need to use it is the JTap.java file. The included test suite is copied from the libtap distro and uses Inline::Java to run the Perl tests through JTap and then compare the results with the libtap results. It's all the same except some minor variations in some diag messages. Note: I don't know much about Java deployment and packaging (and to be frank I don't even use Java all that much), so if anybody is interested in grabbing ownership and maintaining this package please just let me know. Cheers, Patrick -- ===================== Patrick LeBoutillier Laval, Qu?bec, Canada From patl at cpan.org Wed Apr 25 15:20:44 2007 From: patl at cpan.org (Patrick LeBoutillier) Date: Wed, 25 Apr 2007 10:20:44 -0400 Subject: [tap-l] Tap for Java In-Reply-To: References: Message-ID: Hi all, I while back I ported libtap to Java. The code can be found here (the are no docs however but usage is similar to libtap): http://svn.solucorp.qc.ca/repos/solucorp/JTap/trunk/ Basically all you need to use it is the JTap.java file. The included test suite is copied from the libtap distro and uses Inline::Java to run the Perl tests through JTap and then compare the results with the libtap results. It's all the same except some minor variations in some diag messages. Note: I don't know much about Java deployment and packaging (and to be frank I don't even use Java all that much), so if anybody is interested in grabbing ownership and maintaining this package please just let me know. Cheers, Patrick -- ===================== Patrick LeBoutillier Laval, Qu?bec, Canada From andy at hexten.net Wed Apr 25 16:00:14 2007 From: andy at hexten.net (Andy Armstrong) Date: Wed, 25 Apr 2007 16:00:14 +0100 Subject: [tap-l] Tap for Java In-Reply-To: References: Message-ID: On 25 Apr 2007, at 15:19, Patrick LeBoutillier wrote: > I while back I ported libtap to Java. The code can be found here (the > are no docs however but usage is similar to libtap): > > http://svn.solucorp.qc.ca/repos/solucorp/JTap/trunk/ > > Basically all you need to use it is the JTap.java file. The included > test suite is copied from the libtap distro and uses Inline::Java to > run the Perl tests through JTap and then compare > the results with the libtap results. It's all the same except some > minor variations in some diag messages. > > Note: I don't know much about Java deployment and packaging (and to be > frank I don't even use Java all that much), so if anybody is > interested in grabbing ownership and maintaining this package please > just let me know. Thanks Patrick. I hope you don't mind - I've taken your mail pretty much verbatim and added it to the Wiki: http://testanything.org/wiki/index.php/JTap Please feel free (you or anyone else) to dive in and edit it. -- Andy Armstrong, hexten.net From scratchcomputing at gmail.com Sat Apr 28 21:40:17 2007 From: scratchcomputing at gmail.com (Eric Wilhelm) Date: Sat, 28 Apr 2007 13:40:17 -0700 Subject: [tap-l] RFC for tap protocol In-Reply-To: References: <638975.68413.qm@web60820.mail.yahoo.com> Message-ID: <200704281340.18259.ewilhelm@cpan.org> (psst. We use this list for the protocol stuff, right?) # from Andy Armstrong # on Saturday 28 April 2007 07:16 am: >On 28 Apr 2007, at 13:16, Ovid wrote: >> Salve Nilsen of Oslo.pm suggested to me that we >> go through the IETF process and get an RFC out there to help improve >> the visibility of TAP. Jos Boumans suggested that I contact him if >> we're going to do this because he deal with IETF all the time. I >> think it's a great idea. >> >> Thoughts? > >Absolutely. Let's do it. I'll third that. I think we're even going to have a pretty easy time meeting the "multiple working reference implementations" criteria. --Eric -- "It is a mistake to allow any mechanical object to realize that you are in a hurry." --Ralph's Observation --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- From publiustemp-tapx at yahoo.com Sun Apr 29 06:47:08 2007 From: publiustemp-tapx at yahoo.com (Ovid) Date: Sat, 28 Apr 2007 22:47:08 -0700 (PDT) Subject: [tap-l] RFC for tap protocol In-Reply-To: <200704281340.18259.ewilhelm@cpan.org> Message-ID: <435212.29895.qm@web60817.mail.yahoo.com> --- Eric Wilhelm wrote: > (psst. We use this list for the protocol stuff, right?) Oops. Yes, you're right :) > I'll third that. I think we're even going to have a pretty easy time > meeting the "multiple working reference implementations" criteria. Ah, cool. I don't know much about the process other than what Salve told me. That sounds like good news. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/