You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by di...@multitask.com.au on 2002/06/29 10:39:27 UTC
[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.
For the jelliers out there, how does this sound?
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by James Strachan <ja...@yahoo.co.uk>.
From: <di...@multitask.com.au>
> 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.
>
> For the jelliers out there, how does this sound?
Great! :-)
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Jeff Turner" <je...@socialchange.net.au>
> On Mon, Jul 01, 2002 at 08:27:09AM +0100, Vincent Massol wrote:
> > Note: WRT to Jelly, try it you may like it ... :-) (If you haven't done
> > so already !).
>
> lol.. Jelly is obviously cool, and I bet if someone integrated it with
> an MVC framework like Maverick, we'd have the makings of a
> Cocoon-killer.
:-)
Though Jelly could also be a nice Generator for Cocoon too!
> I was just questioning it's relevance to functional testing, where I
> have first-hand experience that Ant does a perfectly adequate job. It
> sounds like Jelly can provide a superset of Ant functionality with few
> disadvantages, so I'll now shut up, go back to making Anteater the
> rockingest little testing framework currently available :) and keep an
> eye out for helping with Latka 2, particularly in the area of defining
> reusable (read: stealable) APIs.
Great! :-)
I understand and hear you Jeff. If Ant does a fine job for what you're
trying to do then thats fine, don't worry about Jelly. Jelly may only be
necessary for 'complex' stuff.
e.g. I'm doing lots of unit testing of JMS / SQL / beans / XML and such like
where the source data for the tests often comes from SQL or XML. Rather than
writing reams and reams of Java tests with different values hard coded in
them, I'm iterating over SQL or XML creating tests, examining SQL results,
doing HTTP and such like. I guess there's many ways to do testing. So long
as everythings plug and play, I guess we all benefit.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Jul 01, 2002 at 08:27:09AM +0100, Vincent Massol wrote:
>
>
> > -----Original Message-----
> > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > Sent: 01 July 2002 02:48
> > To: Jakarta Commons Developers List
> > Subject: Re: [jelly] http and validation tag libraries
> >
>
> [snip]
> >
> > 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?
> >
>
> - Mostly the tools and the front ends (TestRunner) : you can find JUnit
> integration in any IDE. In addition, why reinvent a new testing
> framework API when there is one already. I do agree with your remark of
> TestCase isolation for functional test cases. However, it does not seem
> to be such a problem to use JUnit for that (see my other email on the
> same thread). That said, I need to verify that what I wrote is correct
I agree that if it does work, and doesn't throw away too much that IDEs
rely on (like testcase's packages), it'll be pretty neat.
> Then you get the following additional benefits :
> - people already know how to use your framework because the interface
> (TestRunner) is standard (de facto)
> - you get documentation/support/etc for free for your testing front end
> - the JUnit name is a good seller ... :-)
:) All sounds good, but if you end up writing your own frontend (jelly
invoked from commandline), it won't be really relevant.
> -Vincent
>
> Note: WRT to Jelly, try it you may like it ... :-) (If you haven't done
> so already !).
lol.. Jelly is obviously cool, and I bet if someone integrated it with
an MVC framework like Maverick, we'd have the makings of a
Cocoon-killer.
I was just questioning it's relevance to functional testing, where I
have first-hand experience that Ant does a perfectly adequate job. It
sounds like Jelly can provide a superset of Ant functionality with few
disadvantages, so I'll now shut up, go back to making Anteater the
rockingest little testing framework currently available :) and keep an
eye out for helping with Latka 2, particularly in the area of defining
reusable (read: stealable) APIs.
--Jeff
> > --Jeff
> >
> > [1] http://aft.sourceforge.net/
> >
> >
> > > James
> > >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [betwixt] testing xml output
Posted by robert burrell donkin <ro...@mac.com>.
On Tuesday, July 2, 2002, at 08:20 AM, James Strachan wrote:
> From: "robert burrell donkin" <robertdonkin@mac.com
>> i've been looking at a few (subtle) betwixt bugs recently. (i'll fix them
>> once i have unit tests that can spot them.) i'm now convinced that we
>> really should be testing the xml output. this leads on to the question of
>> how to create these tests.
>>
>> i could probably start looking into xmlunit (in the sandbox) or is there
>> a
>> better way...?
>
> I've not looked too deeply into xmlunit but it seems like a good idea, so
> by
> all means go for it.
i've taken a look at what they have and it doesn't appear to be what i
need. what i need is to verify that the xml output is correct with the
right elements and attributes being created. i think that the easiest way
to do this will be to use a file with the correct xml in and compare DOM
trees.
xmlunit doesn't seem to be a very active. i think that i'll create the
stuff that i need in test for the moment. maybe later it could be
consolidated into xmlunit.
> Incidentally I'm attempting to add a JellyUnit module to Jelly so that we
> can perform XML based unit tests using either XPath or schemas like DTDs,
> RelaxNG or XML Schema - it should be all there in a week or so.
cool. maybe you should add sometime to the jakarta newsletter about all
the progress that's been made with jelly.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [betwixt] testing xml output
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "robert burrell donkin" <robertdonkin@mac.com
> i've been looking at a few (subtle) betwixt bugs recently. (i'll fix them
> once i have unit tests that can spot them.) i'm now convinced that we
> really should be testing the xml output. this leads on to the question of
> how to create these tests.
>
> i could probably start looking into xmlunit (in the sandbox) or is there a
> better way...?
I've not looked too deeply into xmlunit but it seems like a good idea, so by
all means go for it.
Incidentally I'm attempting to add a JellyUnit module to Jelly so that we
can perform XML based unit tests using either XPath or schemas like DTDs,
RelaxNG or XML Schema - it should be all there in a week or so.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [betwixt] testing xml output
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 7/1/02 2:58 PM, "robert burrell donkin" <ro...@mac.com> wrote:
> i've been looking at a few (subtle) betwixt bugs recently. (i'll fix them
> once i have unit tests that can spot them.) i'm now convinced that we
> really should be testing the xml output. this leads on to the question of
> how to create these tests.
>
> i could probably start looking into xmlunit (in the sandbox) or is there a
> better way...?
>
> - robert
Look at the scarab directory in the test directory. You can use that as your
basis as the output gets munged there as well... =)
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[betwixt] testing xml output
Posted by robert burrell donkin <ro...@mac.com>.
i've been looking at a few (subtle) betwixt bugs recently. (i'll fix them
once i have unit tests that can spot them.) i'm now convinced that we
really should be testing the xml output. this leads on to the question of
how to create these tests.
i could probably start looking into xmlunit (in the sandbox) or is there a
better way...?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Jeff Turner" <je...@socialchange.net.au>
> I'll give that a try. The thing is, everyday functional testing doesn't
> seem to *need* Jelly's XML pipelining, expression language, or
> procedural flow control. So far, I've found Ant's declarative style to
> suit functional testing quite well, and it's other deficiencies are
> work-aroundable.
Agreed - I don't think a lot of functonal testing *needs* Jelly though it'll
be interesting to see what kind of things can be done. Certainly its for
'advanced stuff' really.
> Yet I can see that Jelly's capabilities, like iterating through XML, may
> prove very useful for advanced functional testing. There may be
> operations like "fetch a WSDL doc, drill down till you hit the ports,
> test each port". Some use-cases like this would help make the goals
> clear.
Well said. I think when the SOAP scripting & testing stuff is working, the
use cases will become more clear. Especially when folks can create
tag-macros for working with SOAP/WSDL/WSIF as well with 'Velocity' (well
Jexl really) & XPath, while mixing and matching Ant tasks & AntEater and
JSTL we'll have a pretty powerful scripting/testing tool. In a couple of
weeks I think the use-cases of Jelly will become much more clear.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by Jeff Turner <je...@socialchange.net.au>.
On Mon, Jul 01, 2002 at 07:07:22AM +0100, James Strachan wrote:
> From: "Jeff Turner" <je...@socialchange.net.au>
> >
> > 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.
I'll give that a try. The thing is, everyday functional testing doesn't
seem to *need* Jelly's XML pipelining, expression language, or
procedural flow control. So far, I've found Ant's declarative style to
suit functional testing quite well, and it's other deficiencies are
work-aroundable.
Yet I can see that Jelly's capabilities, like iterating through XML, may
prove very useful for advanced functional testing. There may be
operations like "fetch a WSDL doc, drill down till you hit the ports,
test each port". Some use-cases like this would help make the goals
clear.
--Jeff
...
>
> James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Jeff Turner" <je...@socialchange.net.au>
> On Sun, Jun 30, 2002 at 08:33:54AM +0100, James Strachan wrote:
> > From: "Vincent Massol" <vm...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] JellyUnit is available (was Re: [jelly] http and
validation tag libraries)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2002-07-22 at 14:31, bob mcwhirter wrote:
> > And would it be possible to tweak the collection of tests to exclude
> > abstract test cases or possible have a process inspect a specified
> > directory and simply run non-abstract tests?
>
> Yah, I think this is mostly a usage issue, really.
>
> If you name abstract tests slightly differently (ie, FooAbstractTest)
> then using <include>/<exclude>, I think you can pick up the right
> ones.
>
> By default, *Test* seems to be the pattern for <include>, which
> seems to be a tad bit broad.
Yeah, I just made a project.xml file for beanutils and all the tests end
with 'TestCase' which seems to work well when test cases are in the same
directory as test classes.
> Though, having junit be smart enough not to run abstract tests
> would also be a plus.
>
> -bob
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] JellyUnit is available (was Re: [jelly] http and validation tag libraries)
Posted by bob mcwhirter <bo...@werken.com>.
> And would it be possible to tweak the collection of tests to exclude
> abstract test cases or possible have a process inspect a specified
> directory and simply run non-abstract tests?
Yah, I think this is mostly a usage issue, really.
If you name abstract tests slightly differently (ie, FooAbstractTest)
then using <include>/<exclude>, I think you can pick up the right
ones.
By default, *Test* seems to be the pattern for <include>, which
seems to be a tad bit broad.
Though, having junit be smart enough not to run abstract tests
would also be a plus.
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] JellyUnit is available (was Re: [jelly] http and
validation tag libraries)
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2002-07-22 at 11:55, James Strachan wrote:
> Just resurrecting an oldish thread for a moment...
>
> I've got the JellyUnit stuff working now so that JUnit tests can be written
> (and dynamically generated) in Jelly script.
>
> http://jakarta.apache.org/commons/sandbox/jelly/jellyunit.html
>
> So Jelly can be used to create TestSuite and TestCase objects, possibly
> dynamically using information from beans, XML, SOAP, SQL etc. Then Jelly can
> run the tests or they can be called from inside any existing JUnit
> TestRunner .
Cool!
Is there anyway we can integrate this into maven so we can dump the
<junit> task all together?
And would it be possible to tweak the collection of tests to exclude
abstract test cases or possible have a process inspect a specified
directory and simply run non-abstract tests?
> From: "Vincent Massol" <vm...@octo.com>
> > > -----Original Message-----
> > > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > > Sent: 01 July 2002 02:48
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [jelly] http and validation tag libraries
> > >
> >
> > [snip]
> > >
> > > 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?
> > >
> >
> > - Mostly the tools and the front ends (TestRunner) : you can find JUnit
> > integration in any IDE. In addition, why reinvent a new testing
> > framework API when there is one already. I do agree with your remark of
> > TestCase isolation for functional test cases. However, it does not seem
> > to be such a problem to use JUnit for that (see my other email on the
> > same thread). That said, I need to verify that what I wrote is correct
> > ...
> >
> > Then you get the following additional benefits :
> > - people already know how to use your framework because the interface
> > (TestRunner) is standard (de facto)
> > - you get documentation/support/etc for free for your testing front end
> > - the JUnit name is a good seller ... :-)
>
> Agreed.
>
> Incidentally the trick to integrating JellyUnit test cases into an existing
> JUnit TestRunner framework is to write a single adapter class as follows,
> where a Jelly script 'suite.jelly' is assumed to be on the classpath in the
> same package as the TestFoo class...
>
> import junit.framework.TestSuite;
> import org.apache.commons.jelly.tags.junit.JellyTestSuite;
>
> /**
> * A helper class to run jelly test cases in a JUnit TestRunner
> */
> public class TestFoo extends JellyTestSuite {
> public static TestSuite suite() throws Exception {
> return createTestSuite(TestFoo.class, "suite.jelly");
> }
> }
>
> James
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.comm
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[jelly] JellyUnit is available (was Re: [jelly] http and validation tag libraries)
Posted by James Strachan <ja...@yahoo.co.uk>.
Just resurrecting an oldish thread for a moment...
I've got the JellyUnit stuff working now so that JUnit tests can be written
(and dynamically generated) in Jelly script.
http://jakarta.apache.org/commons/sandbox/jelly/jellyunit.html
So Jelly can be used to create TestSuite and TestCase objects, possibly
dynamically using information from beans, XML, SOAP, SQL etc. Then Jelly can
run the tests or they can be called from inside any existing JUnit
TestRunner .
From: "Vincent Massol" <vm...@octo.com>
> > -----Original Message-----
> > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> > Sent: 01 July 2002 02:48
> > To: Jakarta Commons Developers List
> > Subject: Re: [jelly] http and validation tag libraries
> >
>
> [snip]
> >
> > 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?
> >
>
> - Mostly the tools and the front ends (TestRunner) : you can find JUnit
> integration in any IDE. In addition, why reinvent a new testing
> framework API when there is one already. I do agree with your remark of
> TestCase isolation for functional test cases. However, it does not seem
> to be such a problem to use JUnit for that (see my other email on the
> same thread). That said, I need to verify that what I wrote is correct
> ...
>
> Then you get the following additional benefits :
> - people already know how to use your framework because the interface
> (TestRunner) is standard (de facto)
> - you get documentation/support/etc for free for your testing front end
> - the JUnit name is a good seller ... :-)
Agreed.
Incidentally the trick to integrating JellyUnit test cases into an existing
JUnit TestRunner framework is to write a single adapter class as follows,
where a Jelly script 'suite.jelly' is assumed to be on the classpath in the
same package as the TestFoo class...
import junit.framework.TestSuite;
import org.apache.commons.jelly.tags.junit.JellyTestSuite;
/**
* A helper class to run jelly test cases in a JUnit TestRunner
*/
public class TestFoo extends JellyTestSuite {
public static TestSuite suite() throws Exception {
return createTestSuite(TestFoo.class, "suite.jelly");
}
}
James
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.comm
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [jelly] http and validation tag libraries
Posted by Vincent Massol <vm...@octo.com>.
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
> Sent: 01 July 2002 02:48
> To: Jakarta Commons Developers List
> Subject: Re: [jelly] http and validation tag libraries
>
[snip]
>
> 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?
>
- Mostly the tools and the front ends (TestRunner) : you can find JUnit
integration in any IDE. In addition, why reinvent a new testing
framework API when there is one already. I do agree with your remark of
TestCase isolation for functional test cases. However, it does not seem
to be such a problem to use JUnit for that (see my other email on the
same thread). That said, I need to verify that what I wrote is correct
...
Then you get the following additional benefits :
- people already know how to use your framework because the interface
(TestRunner) is standard (de facto)
- you get documentation/support/etc for free for your testing front end
- the JUnit name is a good seller ... :-)
-Vincent
Note: WRT to Jelly, try it you may like it ... :-) (If you haven't done
so already !).
>
> --Jeff
>
> [1] http://aft.sourceforge.net/
>
>
> > James
> >
>
> --
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sun, Jun 30, 2002 at 08:33:54AM +0100, James Strachan wrote:
> From: "Vincent Massol" <vm...@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 ;) ;)
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:
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.
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?
--Jeff
[1] http://aft.sourceforge.net/
> James
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [jelly] http and validation tag libraries
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Vincent Massol" <vm...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [jelly] http and validation tag libraries
Posted by Vincent Massol <vm...@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.
-Vincent
>
> For the jelliers out there, how does this sound?
> --
> dIon Gillard, Multitask Consulting
> Work: http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>