jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Dubois <jul...@julien-dubois.com>
Subject Re: Server Side Testing ejb implementation code
Date Sun, 14 Sep 2003 18:42:38 GMT
Hi Vincent,

I had a look at the "Cactus goals" page, and I've got some comments.

1. From my point of view, Cactus seems to be great for testing the 
presentation layer of a J2EE application (servlets, JSPs, taglibs...).
But the thing that really interests me is Session EJB testing, as :

- I'm using Struts. My JSPs are pretty simple (thanks Tiles & the several 
third-party taglibs), and completly dumb (they just do presentation, no 
logic). I don't need to write servlets or taglibs.

- For the persistance layer I trust my app server (for entity beans) or 
Hibernate.

So as long as Session EJBs testing is not easy to do, I don't have much use 
for Cactus.

2. Some of my applications do not have a presentation layer. Testing them with 
Cactus would be very difficult. 

3. Mock objects are less and less useful. Using mock objects for testing 
servlets could be interesing, but a complete app server is something a lot 
more complicated. It's so easy to deploy your EAR in a real app server, why 
bother using mock objects??

4. I think using DbUnit with Cactus makes a lot of sense.
a. Because it is difficult to get a database in a known state by just using 
the EJBs.
b. Because sometimes the only way to validate a Session bean method is to have 
a look inside the database tables.

Just my 0.02 Euros.

Julien.

Le Dimanche 14 Septembre 2003 14:14, Vincent Massol a écrit :
> Hi Julien,
>
> Yes, ATM, there is a limitation in Cactus when it comes to testing EJBs.
> As we don't have an EJB redirector yet, we have to go through the
> remote/local interface. This is only the case for EJB. For all other
> types of J2EE components it works fine.
>
> Security roles should not be an issue. You have to decide what kind of
> test you want (functional or unit test). If you want to perform unit
> testing, then you want to test the fine-grained details of the code
> implementation. Simply do not use security in your deployment
> descriptors for cactus tests for example. Or create a valid EJB security
> context before calling the EJB to test.
>
> WRT form-based authentication, it is already implemented.
>
> Your "idea" of the "root" Session Bean is exactly what is planned! :-)
> See the todo page on the Cactus web site.
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Julien Dubois [mailto:julien@julien-dubois.com]
> > Sent: 24 June 2003 23:09
> > To: Cactus Users List
> > Subject: Re: Server Side Testing ejb implementation code
> >
> > Hi Martin, hi everybody,
> >
> > I'm a Cactus newbee too, and I'm having kind of the same problems. I'd
> > like to
> > tests my EJBs.
> >
> > Like Martin, I can only tests EJBs which are visible to the servlet
> > container,
> > and my Entity Beans are definitly not visible. This is not a major
> > problem,
> > my logic is in the Session Beans and they're the ones I'd like to
>
> test.
>
> > However, they're protected by a lot of different security roles, and I
> > find it
> > very difficult to test them from Cactus. Implementing form-based
> > authentication in Cactus would help (I see that is being worked on in
>
> the
>
> > CVS
> > tree), however it would not solve all my problems.
> >
> > So I'm toying with one idea :
> > Why not make a Session Bean, which would run as "root" (a unix-like
>
> "root"
>
> > role should exist), and which would inherit from
>
> junit.framework.TestCase?
>
> > It's just an idea, has anybody done something like that before??
> >
> > Julien Dubois.
> >
> > On Tuesday 24 June 2003 19:56, Bayly, Martin wrote:
> > > Hi
> > >
> > > We're looking into using Cactus to improve integration unit testing.
> >
> > We're
> >
> > > planning on using Cactus primarily for testing our ejb interfaces,
>
> but
>
> > > ideally we'd like to use it for server side testing of lower level
> >
> > classes
> >
> > > in the ejb implementations e.g. data access classes for example.
> > >
> > > This raises the issue of visibility of those classes to the web tier
> >
> > where
> >
> > > the cactus unit tests run. Currently, our deployed build is pretty
>
> loose
>
> > > and everything can see pretty much everything else.  However, we're
>
> in
>
> > the
> >
> > > process of tightening this up with the intention being that the web
>
> tier
>
> > > will only be able to see the ejb interfaces and the classes exposed
>
> by
>
> > > those interfaces.  However, it won't 'conceptually' be able to see
>
> ejb
>
> > > implementation details.
> > >
> > > To a certain extent this depends on the class loading scheme used by
>
> the
>
> > > container - we're currently using weblogic 6 and in the current
>
> weblogic
>
> > > class loading scheme the web app can see all the classes in the ejb,
>
> as
>
> > all
> >
> > > ejbs are loaded using a single class loader, and the web app is
>
> loaded
>
> > as a
> >
> > > child class loader of the ejb class loader.
> > >
> > > However, we don't particularly want to be tied to the current
>
> weblogic
>
> > > scheme.
> > >
> > > I was just wondering if other people have come across this issue and
>
> how
>
> > > have they tackled it.  Does it mean we're going to have to deploy
>
> with a
>
> > > different structure for running server unit tests?  I was kind of
>
> hoping
>
> > > the only difference in our test/production build would be the
>
> deployed
>
> > test
> >
> > > cases and cactus jars.
> > >
> > > Cheers,
> > > Martin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-user-help@jakarta.apache.org


Mime
View raw message