Hi,
i agree ant is not the right tool to use.
about http unit you can get the response as an XML DOM
(WebResponse.getDOM()), too.
This way you can check WML, XML, etc, I tried this a bit.
About the other toolkits I have no experience, but I some
good experiences with httpunit.
----- Originalnachricht -----
Von: Jeff Turner <[EMAIL PROTECTED]>
Datum: Sonntag, September 23, 2001 5:53 am
Betreff: Re: testing/performance framework for Cocoon
> On Fri, Sep 21, 2001 at 08:33:13AM -0700, Ovidiu Predescu wrote:
> >
> > Hi,
> >
> > One of the most frustrating parts of developing Cocoon is the
> lack of
> > a testsuite. Since I've started working with Cocoon, I've seen a
> > feature working fine now, and completely broken in the next
> day's CVS
> > snapshot. As a result I'm trying to come up with some framework to
> > have automated regression testing, and maybe performance testing as
> > well.
> [..]
> > The Ant based approach requires some extension tasks to be
> > defined. Most of them seem to be easy to implement, only one of them
> > is more difficult.
> [..]
> > Below is a list of Ant extension tasks:
> >
> > <database> - describe the database used to store the results.
> >
> > <test> - defines a new test. Each test has a name, and whether the
> > time taken to execute it should be logged in the database or
> not. The
> > assumption is that some tests are really just that, while others are
> > really performance measurements.
> >
> > <url-get> - makes an HTTP GET request to an URL
> >
> > <url-post> - makes an HTTP POST request to an URL
>
> I recently required something like this. I first played around
> with Tomcat's
> Ant task for doing unit testing (see
> jakarta-tomcat-4.0/tester/src/bin/tester.xml). It's used like this:
>
> <project name="Tester" default="all">
> <taskdef name="tester"
> classname="org.apache.tester.TestClient"/> ..
> <tester host="${host}" port="${port}" protocol="${protocol}"
> request="/index.html" debug="${debug}"
> status="200"/>
> <tester host="${host}" port="${port}" protocol="${protocol}"
> request="${context.path}/WrappedGolden01"
> golden="${golden.path}/Golden01.txt"/>
> <tester host="${host}" port="${port}" protocol="${protocol}"
> debug="${debug}"
> request="${context.path}/protecte
> inHeaders="Authorization:Basic dG9tY2F0OnRvbWNhdA=="
> ..
>
> However, this system is rather monolithic and hard to extend. All
> new tests
> would have to be added to TestClient directly.
>
> I had a brief poke at httpunit, but it seemed to be more oriented
> at HTML
> testing.
>
> So I'm now playing with a testing tool called Latka, developed by
> MorganDelagrange in jakarta-commons/latka.
>
> "Latka is a functional (end-to-end) testing tool. It is
> implemented in Java,
> and uses an XML syntax to define a series of HTTP (or HTTPS)
> requests and a
> set of validations used to verify that the request was processed
> correctly."
> -- http://jakarta.apache.org/commons/latka/index.html
>
> It has quite a few validation techniques already, but none
> specific to XML.
> However, it's very easy to write new validators. I had a MIME type
> validator(eg check for text/xml) and an XML validation validator
> going in a few hours. I
> expect it would be quite trivial to implement an XPath test:
>
> > <check> - checks an XPath in the XML document returned by an
> <url-get>
> > or <url-post>.
>
> Here's a sample XML file, doing a few tests against XML services:
>
> <?xml version="1.0" standalone="no"?>
> <!DOCTYPE suite SYSTEM "../conf/suite.dtd">
> <suite defaultHost="newgate.socialchange.net.au" label="newgate">
>
> <request path="/sightings/servlet/WFSSightingsServlet"
> label="WFSSightings"> <validate>
> <statusCode label="valid HTTP status code" code="200"/>
> <mimeType label="Correct XML MIME type" value="text/xml"/>
> </validate>
> </request>
>
> <request host="clearinghouse1.fgdc.gov"
> path="/scripts/ogc/ms.pl?WMTVER=1.0&request=CAPABILITIES"
> label="SCO WMS">
> <validate>
> <mimeType value="text/xml"/>
> <xmlValidator/>
> </validate>
> </request>
> </suite>
>
> (David Crossley and other GIS people will understand those tests;)
>
> Note that it doesn't use Ant. I suspect this is actually a good
> thing. Ant 1.x
> is not flexible enough to be easily repurposed as a http testing
> engine. This
> will apparently be fixed in Ant 2, which will be a generic "task
> executionengine", but for now, it's probably harder to turn Ant
> into something it's not,
> than to start again. For instance, there have been *many*
> submissions of an
> iterate, or <foreach> task:
>
> > <iterate> - creates a "for" loop so we can do very simple loops
>
> But the ant-dev team are very much against turning Ant into an XML
> scriptinglanguage, and reject such tasks.
>
> That thought leads to one serious suggestion: how about
> implementing the tests
> in Python, and then using a Python-to-Java compiler
> (http://jython.sourceforge.net/) to generate bytecode?
>
> > <spawn> - creates a given number of threads and executes the tasks
> > specified as children. This could be used to simulate multiple
> clients> connecting to a URL.
>
> It may be possible to hack Ant 1.4's <parallel> task to do this
> sort of thing.
> However, the ant-dev committers would be unlikely to accept your
> addition,since it amounts to an <iterate> task.
>
> So I think the options (in order of my preference;) are:
> - use and extend Latka to do the testing (lots of work)
> - write tests in python, compile to java (less work)
> - turn Ant into testing tool with testing-specific tasks
> - use httpunit or another framework
>
> --Jeff
>
> [..]
>
> > Greetings,
> > --
> > Ovidiu Predescu <[EMAIL PROTECTED]>
> > http://orion.rgv.hp.com/ (inside HP's firewall only)
> > http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU,
> Emacs, other stuff)
>
> -------------------------------------------------------------------
> --
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
begin:vcard
n:Huber;Bernhard
fn:Bernhard Huber
version:2.1
email;internet:[EMAIL PROTECTED]
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
