You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by James Strachan <ja...@yahoo.co.uk> on 2002/07/22 17:55:22 UTC
[jelly] JellyUnit is available (was Re: [jelly] http and validation tag libraries)
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] 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>