Bernhard,
On Sun, 23 Sep 2001 12:22:48 +0000 (GMT), Bernhard Huber <[EMAIL PROTECTED]> wrote:
> 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.
I looked at httpunit, but I feel it's too HTML oriented. What I need
is both a more generic tool, an a higher level tool, that would allow
testing of XML Web services among other things. httpUnit doesn't
provide me this kind of thing.
> ----- 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
