Hi all, Just a few comments. OK, maybe a few more than a few. :)
----- Original Message ----- From: "Jeff Turner" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Thursday, May 16, 2002 12:57 AM Subject: Re: Latka & Anteater > On Wed, May 15, 2002 at 10:26:47PM -0500, Ivelin Ivanov wrote: > > > > Can some of the Latka experts please comment on how Latka compares to > > Anteater (which emerged from Cocoon)? > > > > http://sourceforge.net/projects/aft/ > > I've worked on both projects, and like both for different reasons. > > Latka pros: > - Strong typing via a DTD. > - Internally, it's got a very nice delegating-SAX-handler model for > adding new elements. On top of that, you can add new custom validators to Latka without recompiling it. I don't know if this is a feature of Anteater or not. That's the real benefit of the delegation model. Since it assumes that the validator will perform its own SAX handling and release to the XML processor when its done, you can customize a validation with any combination of arbitrary elements (although you'll probably want to retain a validatable DTD). I'd like to try to extend this plugability in other areas. I think it may be possible to plug in entirely new top level tasks (e.g. plug in XML-based GUI tests like those in "Abbot" http://sourceforge.net/projects/abbot/). > - Decent XML reporting. > - After all Dion's work, it's docs are rather good. I might add: - Decent web interface It's still a pain to build, so I hope to fix that. I like Latka's constrained syntax. In my view, it makes writing tests easier for folks who are less sophisticated technically. A trained QA engineer could write simple Latka tests quite easily. As in all things, it depends on what your requirements are. > Latka cons: > - A PITA to compile, due to it's many dependencies. Hopefully that's > changed with Maven. Yup. > - The XML file is a bit hard to comprehend at first, due to the use of > &entities; > - Inflexible XML syntax (see below for definition of 'flexible':) > > > Anteater pros: > - It's based on Ant (it's really a bunch of Ant tasks). This makes it > wonderfully flexible: > - I can parametrize tests, by defining variables like ${host}, > ${port}, ${debuglevel} as properties, and reuse them throughout the > script. Actually, you can do that in Latka too (and I highly recommend making at least the host and port configurable in most cases). You can configure variables with any combination of command-line properties and prop files. > - Through the use of targets, I can group tests together, and with > the 'depends' attribute, can have common groups of tests. Latka's > approach (entities) is workable but not half as nice & intuitive. Yeah, that is one feature that I miss. The Latka way to do it is to group distinct tests into separate files and combine them in different XML files. Some advantages wrt. organizing large test suites, but not as intuitive. > - I can <echo> whenever I want, or <fail> halfway through a test. You can "echo" now in a Latka suite via the <reportMessage/> tag. It doesn't work quite the same way as an Ant echo though. Latka doesn't have a fail tag, although it probably could. > - I can use Ant's <parallel> to test multiple servers at once. Another nice feature. I'd like to see Latka do something like that someday. > - I can capture the matched <regexp> or <xpath> value as a property, > and print it out for debugging. > - I can do conditional logic, eg "If response code is 200, do a > <regexp> test, else if response code is 404, set the ${failed} > variable, else <fail> the test". > > - It supports testing of interactive services like SOAP, which need to > hold a 'conversation' with another HTTP server. It does this by > launching an embedded Tomcat instance, and then registering > 'listeners' which validate incoming requests and return specified > responses. Apart from SOAP/web services testing, this allows one to > 'unit test' a website: have an Ant script launch the webapp, test it > and shut it down again. > > Here's how you'd launch a Tomcat, and then send a query to > it. Both the request and response are validated with <match> tags: > > <servletContainer port="8101"/> > > <http description="Test the regexp matcher"> > <parallel> > <listener path="/good.html"> > <match> > <method value="GET"/> > <sendResponse href="test/responses/good.html" /> > </match> > </listener> > > <sequential> > <sleep seconds="1"/> > <httpRequest path="/good.html"> > <match> > <regexp mustMatch="false" assign="n">exception</regexp> <!-- mustn't contain the text 'exception' --> > <regexp assign="m"><![CDATA[.*<html>.*<body.*<p.*You sent the proper request.*</p>.*</body>.*</html>]]></regexp> > </match> > </httpRequest> > </sequential> > </parallel> > </http> > > > Anteater cons: > - Being based on Ant, Anteater is 'loosely typed', ie scripts aren't > checked against a DTD. > - It's not 1.0-quality yet. Ie, the README file is misleading, and you > must symlink build/anteater-0.9.x to build/anteater in order to run > the tests. The docs in CVS are rapidly approaching Latka quality, but > not on the website yet, so it's best to learn by example (see > test.xml). > - I don't think there is any XML reporting mechanism beyond Ant's > standard ability to attach project listeners, which may not provide > sufficient detail (I haven't tested). > > > Btw, there's no reason why Anteater and Latka couldn't share a common > API for 'validators'. I'd like to try this, but for now it's less effort > just to duplicate them (there's not that many). Me too. > > HTH, > > --Jeff > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
