commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: [jelly] http and validation tag libraries
Date Mon, 01 Jul 2002 06:07:22 GMT
From: "Jeff Turner" <jeff@socialchange.net.au>
> On Sun, Jun 30, 2002 at 08:33:54AM +0100, James Strachan wrote:
> > From: "Vincent Massol" <vmassol@octo.com>
> > > > -----Original Message-----
> > > > From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> > > > Sent: 29 June 2002 09:39
> > > > To: commons-dev@jakarta.apache.org
> > > > 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 ;) ;)

:-)

Actually Jeff, Jelly should work really nicely with Anteater. You should be
able to run all your Anteater stuff inside Jelly (since Jelly can run Ant
tasks etc) then we can mix and match all of our testing makarkey. If nothing
else you'd get decent expression languages like Jexl (which is spookily
close to Velocity) to work with beans and XPath to work with XML and some
tags for working with SQL and such like.


> 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.

Will take a peek, thanks for the heads up.

Early experimentation in this area is doing some basic stuff but ultimately
I'd like to be able to validate whole 'conversations' in a distributed HTTP
/ SOAP / JMS sense.


> > 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:
>
> http://opensource.socialchange.net.au/anteater/report/frames/
>
> 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.

Agreed.


> 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.

Thanks for that.


> > 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?

:-)

I guess its mostly just the ability to run specific tests or groups of tests
or all tests from some 'controller' which might be the command line, IDE,
swing etc along with being able to integrate cleanly with any
JUnit-reporting stuff.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.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>


Mime
View raw message