Re: Mock Objects vs In-Container/Cactus

[Vincent Massol]

Title: RE: Mock Objects vs In-Container/Cactus

Jerome,   I'm not sure we are talking about the same thing when referring to MockObjects. What I mean is described in http://www.sidewize.com/company/mockobjects.pdf and I have a short summary on pros and cons that I can see when compared with Cactus In-container testing on http://jakarta.apache.org/commons/cactus/mockobjects.html.   I don't see how we could dynamically generate Mock Objects as these objects are used to write the test cases (which are static).   I think that what you mean is for the EJB client to be able to call a mock EJB or the real EJB (with a flag to change from one to another), is that right ? Mock Objects (in my definition) are used to simulate a method's interaction with it's surrounding, meaning we mock domain objects manipulated by the method. I'm referring to Mock objects in the context of *unit* testing, not more coarse grained unit/functional testing where you would want to simulate whole parts of a system, like a component in the example of EJB. This is because the goal of Cactus is to unit test these components.   Thanks. Vincent.   ----- Original Message ----- From: Jerome Banks To: [EMAIL PROTECTED] Sent: Monday, May 14, 2001 7:43 PM Subject: RE: Mock Objects vs In-Container/Cactus Alex,Vincent,Craig,   I originally thought that Cactus was a MockObject   implementation. This is probably sufficient for   most of our Servlet testing, but isn't really   good for many specific things like redirects   or includes. If your application is heavily   dependent on these , it could be a problem ...    For EJB testing, MockObjects is quite necessary.   One wants to test the client code, while keeping the   server code stable, (and also want to run JUnit without   having an EJB server up and running all the time.) We   actually generate our MockObjects from interfaces, using   reflection( Is that what the sourceforge project is about ???)   Then one needs to isolate the EJBHome, and Finder mechanism,   ( get your EJB home through a specific function , rather then   using JNDI specificially, and have a flag whether that function    returns a real EJB or a MockEJB ) to get the right interface.  When you want to test the real semantics, have the finder return   a "colocal" implementation, so the real EJB's get called locally,    without an EJB server running( This might require some EJB   container services, like connections, however ).... --- jerome > -----Original Message----- > From: Alex Fernández [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 14, 2001 4:08 AM > To: [EMAIL PROTECTED] > Subject: Re: Mock Objects vs In-Container/Cactus > > > Hi Vincent! > > I like Mock Objects a lot. In fact, without even knowing > them, we built > a similar framework for servlets: mock Request, Response, Session, > Context. > > They are really simple objects, that include a set...() for every > get...() in the interface. E.g., in HttpServletRequest you have a > getParameter(), so in our Request we have a setParameter(). We do not > simulate an HttpServlet, since it didn't seem necessary at the time -- > we do not use log() or any other container-specific stuff. > > Perhaps our classes might be used; we have no problem in changing the > name/package/license. They were developed as part of a project that > failed, so the code is orphaned. > > Also, we're in sore need of something else. As part of a new project, > which uses EJB, we'd like to simulate an EJB container with mock > objects. Is there any way we can do it? Of course, simulating just the > EJB or just the servlet should be piece'o'cake, but we need > to simulate > calls from the servlet to an EJB, without the added cost of > testing the > container: >       servlet -> EJB Container -> EJB > > If you care to have a look at what we've got, I'll send them along. > > Un saludo, > > Alex. > > Vincent Massol wrote: > > > > I have discovered this week a new strategy for unit testing > code : it's > > called Mock Objects. It enables unit test of all kinds : > standard java code, > > servlet, EJBs, ... The strategy is differrent from the we > use in Cactus > > (that I have named "In-Container testing"). Thus, I have > written an article > > explaining both strategies and the pros and cons of each. > > > > It is available on the Cactus web site at : > > http://jakarta.apache.org/commons/cactus/mockobjects.html > > > > I would very much like to have your opinion on that > subject. If I receive a > > lot of positive answers, it might mean that we'll change > the way Cactus work > > in order to do it the Mock Object way. As this is a big > change, I'd like to > > have your opinion on that. > > > > I guess Struts users should be very interested in it as it > could provide > > very efficient way of unit testing struts code (The > benefits are actually > > the same of any Jakarta framework users). > > > > I'm very excited about this ... Please tell me quickly what > you think ! > > > > Thanks for your time. > > > > Vincent Massol >