commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [jelly] http and validation tag libraries
Date Mon, 01 Jul 2002 01:47:32 GMT
On Sun, Jun 30, 2002 at 08:33:54AM +0100, James Strachan wrote:
> From: "Vincent Massol" <>
> > > -----Original Message-----
> > > From: []
> > > Sent: 29 June 2002 09:39
> > > To:
> > > Subject: [jelly] http and validation tag libraries
> > >
> > > I've been looking at how Latka could leverage Jelly's infrastructure,
> > and
> > > it boils down to a few things:
> > > - a http tag library covering latka's existing tags
> > > - a 'validation' tag library for validating results/jelly variables
> > > - a junit bridge to make jelly scripts runnable as unit tests.
> >
> > Wrapping a Jelly script around a JUnit TestCase so that it can be run by
> > any TestRunner would be real nice .. ! However, I think that will break
> > the JUnit model a bit because you'll end up having only one testXXX()
> > method (in the bridge) and all your test cases will be in jelly script.
> >
> > Ideally we would need a way to have as many testXXX() methods as there
> > are test cases in our jelly scripts ... but how ?
> >
> > Let's say you have an XML script describing your test cases like the
> > following :
> >
> > <tests>
> >   <test name="xxx">
> >   [...]
> >   </test>
> >   <test name="yyy">
> >   [...]
> >   </test>
> > </tests>
> >
> > We would need the ability to generate a TestCase class with testXxx()
> > and testYyy() methods ... but that's not very easy to do (thinking aloud
> > really).
> >
> > We could have a specific TestRunner but then we loose the ability to run
> > our tests in any existing TestRunner, including all JUnit integrations
> > in IDEs.
> Agreed. I'd really like to be able to write test cases in Jelly and will be
> trying to get something going next week to do this. I really want to use
> Jelly for unit testing of XML, SQL, JMS, HTTP, SOAP testing and such like
> where Jelly is the 'script glue' for orchestrating the tests.

Embrace the Dark Side! Abandon this Jelly nonsense and come bang your
head against Ant oddities with Ovidiu and I in Anteater ;) ;)

Seriously, for advanced SOAP (and JMS?) testing, you'll need something
like Anteater's ability to validate *incoming* requests, not just issue
outgoing requests. You're welcome to steal code of course.

> My early thought was to just try to get a JellyTestRunner working that ran
> all the tests and generated the same XML output that the JUnit runner from
> Ant uses. So then the JUnitReport stuff would integrate traditional JUnit
> tests with JellyUnit tests (and they'd all appear together on the Maven
> generated website).

This is what I did for Anteater[1]. The output can be seen at:

The interface with the rest of the system is the Logger interface, which
has callback methods startTest(), endTest() etc. It would be cool if we
could come up with some common APIs like that, particularly for logging
and validators.

One suggestion: JUnit tests are all 'scoped' by the TestCase's Java
package.  Each test belongs to a group (a package). This notion of
scoped tests is built into the JUnit reporting stylesheets, and
presumably other reporting mechanisms in IDEs. If you want to reuse all
this infrastructure, it's a good idea to build in the idea of a
functional test's scope / namespace / group in from the beginning. It's
a useful concept in any case; tests can be grouped by purpose, eg "Test
the Cocoon webapp", "test Jakarta sites". Scopes can also be a neat way
of reducing test script verbosity; eg if my test is in scope 'jakarta',
it inherits the 'jakarta' session and logger. This is currently being
implemented in Anteater.

> I've not really dealt with JUnit IDE integration so I'm not sure how
> easy/possible this is gonna be but I think making a single JellyTestSuite
> should be pretty simple to do, which hopefully could then be used inside an
> IDE. Most of the IDE stuff (at least going from the awt and swing UI stuff
> in JUnit) loooks like it will accept a TestSuite object so this approach
> should work I think. Anyone see any floors in this plan?

Somewhat curious as to why everyone's so keen to reuse the JUnit API 8-)
I've found it to be so tightly engineered and 'pattern dense' that it's
hard to reuse outside it's intended scope. JUnit goes to a lot of effort
to isolate TestCases, and for functional testing we *want* to share
information like session data. Once you've thrown away the testXxx()
method introspection, startUp(), tearDown(), and all that, what's left?



> James

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message