commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject [jelly] JellyUnit is available (was Re: [jelly] http and validation tag libraries)
Date Mon, 22 Jul 2002 15:55:22 GMT
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.

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" <>
> > -----Original Message-----
> > From: Jeff Turner []
> > 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 ... :-)


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");


Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message