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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
