You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jason van Zyl <ja...@zenplex.com> on 2002/07/22 20:27:58 UTC
Re: [jelly] JellyUnit is available (was Re: [jelly] http and
validation tag libraries)
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>
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>