commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: [jelly] http and validation tag libraries
Date Sun, 30 Jun 2002 08:17:25 GMT
No flaws, but maybe some ideas.... shooting the breeze here...

How about a new Script subclass, TestScript?, which can be executed as a 
JUnit Test as well as a Jelly Script? on the runTests method of JUnit's 
Test, it simply run's the body. Each 'test' would be held in a test tag.

Then some special assert tags to wrap it all up.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers

"James Strachan" <james_strachan@yahoo.co.uk> wrote on 06/30/2002 05:33:54 
PM:

> 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.
> 
> 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).
> 
> Though I'd like even closer integration if possible so that clean IDE
> integration works too. So maybe we could have a special TestSuite that
> (JellyTestSuite) that runs the jelly script and creates the individual
> TestCase objects dynamically from Jelly script? Using your example above 
a
> single JellyTestSuite could generate test cases 'xxx' and 'yyy' which 
could
> then be invoked on demand via an IDE or all in one go etc.
> 
> 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?
> 
> 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>
> 


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