commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: [jelly] http and validation tag libraries
Date Sun, 30 Jun 2002 09:07:48 GMT
Hi dIon and James,

> -----Original Message-----
> From: dion@multitask.com.au [mailto:dion@multitask.com.au]
> Sent: 30 June 2002 01:27
> To: Jakarta Commons Developers List
> Subject: RE: [jelly] http and validation tag libraries
> 
> Hey Vincent,
> 
> don't think about it as too similar to the way we write test cases.
> 
> JUnit is built so that the testXXX() methods are not a requirement. We
> don't have to generate the methods themselves, we could have an
adaptor
> that overrides the run method of the test class for example.

Yes, I think you are right ... Here are some more info :

The BaseTestRunner (which is inherited by all JUnit test runners)
creates a TestSuite object (either by calling your test case static
suite() method or by automatically creating a new test case instance for
each method that start with "test" and which return void).

Thus, our first requirements is that our JellyTestCase must have a
static suite() method that only registers one test. Let's call it
testAll().

Then the TestRunner will create a TestResult which will hold all the
results and which is the key to us (and our salvior !).

The TestRunner then calls TestSuite.run(TestResult) which in turn runs
TestCase.run(TestResult) on all the TestCase that were created. In our
case there is only one as we only registered the testAll() method. Thus
our JellyTestCase is only instanciated once and it's run(TestResult)
method is now called.

One method we need to override is runBare() which in normal test cases
calls setUp(), then runTest() and tearDown() in sequence. In our
implementation it will only call runTest().

At last we need to override runTest() and hand over to Jelly.

We may also want to support the notion of Failure (as opposed to Error).
To support this we simply need to throw an AssertionFailedError
exception whenever there is a failure (maybe through a <junit:fail>
tag).

Now, the hard part is to notify the test runner test by test about the
progress.

I believe we can achieve this by doing the following :

- Create a JellyTestResultWrapper class that wraps the JUnit TestResult
class. We will delegate all calls to the original TestResult except for
the following methods : startTest(Test) and endTest(Test) which needs to
be empty (i.e. do nothing).

- We will create the JellyTestResultWrapper by overriding
TestCase.run(TestResult) :

	public void run(TestResult result) {
		new JellyTestResultWrapper(result).run(this);
	}

- Then we need to add 2 methods to our JellyTestResultWrapper :
startJellyTest(Test) and endJellyTest(Test). They will perform the same
as the original TestResult methods startTest() and endTest().

- Then during the execution of TestCase.runTest(), which has called the
Jelly script, we need to call, before and after each test our
JellyTestResultWrapper.startJellyTest(Test) and endJellyTest(Test).

The question is how ? Maybe we need some <junit:startTest> and
<junit:endTest> tags.

This should enable us to see the progress in the JUnit TestRunner as our
tests are executed!

So, yes, dIon, you are right, it should be possible!

That would be real great!

Thanks
-Vincent


> --
> dIon Gillard, Multitask Consulting
> Work:      http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
> 
> "Vincent Massol" <vmassol@octo.com> wrote on 06/30/2002 04:04:01 AM:
> 
> >
> >
> > > -----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:
> <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>



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