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
>
