Mailing-List: contact cactus-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Cactus Users List" <cactus-user@jakarta.apache.org>
From: "Vincent Massol" <vmassol@octo.com>
To: "'Fred Loney'" <loney@spiritedsw.com>,
        "'Cactus Users List'" <cactus-user@jakarta.apache.org>
Cc: "'Oliver Rossmueller'" <oliver@oross.net>
Subject: RE: JUnitEE and Cactus
Date: Mon, 26 Aug 2002 16:47:48 +0100
Organization: OCTO Technology
Message-ID: <000701c24d17$ee26ec30$0200a8c0@octovma>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <002f01c24d13$b99ac300$3227e40c@spiritedsw.com>
Importance: Normal

Hi Fred,

Interesting points. See below.

> -----Original Message-----
> From: Fred Loney [mailto:loney@spiritedsw.com]
> Sent: 26 August 2002 16:18
> To: Cactus Users List
> Cc: 'Oliver Rossmueller'; vmassol@octo.com
> Subject: Re: JUnitEE and Cactus
> 
> If I might interject a comment:
> 
> > > Disadvantages of Cactus
> > > ...
> > > - requires special test case super class
> >
> > yep. Not sure this is really a problem though. Do you have an issue
in
> > mind ?
> 
> Surprisingly, this turns out to be a annoying encumbrance. Two
examples:
> 
> 1) Some tools with built-in junit support key off of a TestCase
subclass
> and don't accomodate a ServletTestCase subclass. E.g., the IntelliJ
idea
> IDE recognizes any TestCase subclass as a candidate under the
Run>Junit
> Tests menu pick, but will only recognize a ServletTestCase if it
> supplies a suite() method. Granted, this is arguably a defect of the
> idea tool, but the point is that any variation from the standard junit
> class structure will inevitably affect the test tool user in
> unpredictable ways.

The tools are getting better here. Yes, this is simply bad programming.
I thought IDEA had fixed this one some time ago (I may be wrong). But
yes this could be an issue.

> 
> 2) It is desirable to make the test infrastructure (remote vs. local)
> orthogonal to the test content. E.g. I use an application framework
that
> insulates business logic from it's distribution and persistence
> characteristics--local, EJB, MDB, XML. A class MyClass with business
> logic could run under several different contexts depending on an
> external configuration. The class MyClass can be tested locally with
> junit class MyClassTest. However, I have found no way to reuse
> MyClassTest with cactus. 

I see. Actually I thought about this a long time ago. In my experience,
the tests you wanted to do on your class are completely different in
you're testing the logic or if you're testing the interaction with the
container and other classes. I do have 2 classes too, but they don't do
the same thing at all (otherwise, the added value is minimal).

For example my logic unit test uses Mock Objects to simulate the
HttpServletRequest. But in Cactus I want to use the real
HttpServletRequest. Thus I can't reuse the same test anyway. If you're
talking about simple java beans with no interaction with the servlet
engine, then there is really no point in testing them in Cactus. There
is some value in having them being tested in a coarser-grained test
though.

> I must instead maintain two test classes,
> MyClassLocalTest and MyClassServerTest, with identical content but a
> different superclass, TestCase and ServletTestCase, resp. Note that
> extension of an abstract base class is not an option, since the base
> class must make a discrete superclass choice. Similarly, delegation to
a
> test helper class with the test content breaks the junit introspection
> paradigm.
> 
> Cactus derivation from a special superclass falls under the category
of
> an annoyance rather than a major problem, but I thought that some
> clarification might be useful.

I'm open to suggestions. What do you propose ?

Thanks
-Vincent


--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>