jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: JUnitEE and Cactus
Date Mon, 26 Aug 2002 15:47:48 GMT
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
> > mind ?
> Surprisingly, this turns out to be a annoying encumbrance. Two
> 1) Some tools with built-in junit support key off of a TestCase
> and don't accomodate a ServletTestCase subclass. E.g., the IntelliJ
> IDE recognizes any TestCase subclass as a candidate under the
> 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
> 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

> 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
> test helper class with the test content breaks the junit introspection
> paradigm.
> Cactus derivation from a special superclass falls under the category
> 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 ?


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

View raw message