commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: [latka][anteater][jelly] possible integration... (was Re: Latka & Anteater)
Date Wed, 30 Oct 2002 12:27:20 GMT
Cactus can use any JUnit test runner. Thus it should be able to use the
exsiting JellyUnit tags with no problem. However, before running the
tests there needs some preparations to make everything automatic:
- packaging the application as a war or ear
- configuring the container
- starting it
- deploying the app in it
- stopping it

These could be easily achieved through a combination of Ant and Jelly
tags, potentially used in a Cactus Tag library which would make the
whole thing easier and more coherent to use?

-Vincent

> -----Original Message-----
> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
> Sent: 30 October 2002 12:17
> To: Jakarta Commons Developers List
> Subject: [latka][anteater][jelly] possible integration... (was Re:
Latka &
> Anteater)
> 
> Sorry to bring up such an old thread. I've just committed a patch
supplied
> by Robert Leftwich which allows some easy testing of servlet request
using
> a
> Jelly library which uses an embedded Jetty server.
> 
> http://cvs.apache.org/viewcvs/jakarta-commons-
> sandbox/jelly/src/test/org/apa
> che/commons/jelly/jetty/defaultServer.jelly?rev=1.1&content-
> type=text/vnd.vi
> ewcvs-markup
> 
> It got me thinking; I've always kept an eye on Latka and Anteater and
it
> seems like they are getting closer and closer each day. Both use some
> degree
> of Ant, Jelly, Maven.
> 
> To make unit testing of Jelly easy, JellyUnit got created which has
JUnit
> integration, assertions, expression support, XPath validation and
schema
> validation (DTD, RelaxNG and XML Schema). Maybe JellyUnit might have
some
> use to both Latka and Anteater to help them fit into a JUnit framework
(if
> they don't already do that).
> Then folks started adding HTTP client and HTTP server tags to Jelly
thats
> starting to blur the lines even more.
> 
> So now we have 3 projects with some overlap. I guess Cactus might
overlap
> here too. I get the feeling all these different projects are starting
to
> travel in the same direction. I'm just wondering what peoples thoughts
> were
> on having some possible integration or sharing of code across the
various
> projects?
> 
> I'm not exactly sure how or what should happen. Sometimes code should
stay
> seperate as it just makes life easier. I just wanted to open a dialog
> really
> to see if we can think of ways to share or reuse code or somehow work
> together to solve the same goals.
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> ----- Original Message -----
> From: "Jeff Turner" <jeff@socialchange.net.au>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Thursday, May 16, 2002 5: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.
> >  - Decent XML reporting.
> >  - After all Dion's work, it's docs are rather good.
> >
> > Latka cons:
> >  - A PITA to compile, due to it's many dependencies.  Hopefully
that's
> >    changed with Maven.
> >  - 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.
> >    - 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.
> >    - I can <echo> whenever I want, or <fail> halfway through a test.
> >    - I can use Ant's <parallel> to test multiple servers at once.
> >    - 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).
> >
> >
> > HTH,
> >
> > --Jeff
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
> >
> 
> __________________________________________________
> 
> Do You Yahoo!?
> 
> Everything you'll ever need on one web page
> 
> from News and Sport to Email and Music Charts
> 
> http://uk.my.yahoo.com
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message