|
Vincent,
I mean MockObjects in the more generatl sense. For Servlets,
the API is frozen ( SerlvetRequest, ServletResponse ) more or
less. For EJB's the signature changes. When we "generate"
the
MockObjects, all we do is implement the EJB interface ( for
the
EJB api in question ) with an empty definition ( return null, or do
nothing)
The developer then modifies it to match his test ( at development
time)
not run time. At run-time, if a unit test is being run, the Finder uses the
generated stub instead of the real EJB
interface.
I think that's the general idea of MockObjects, although
terminology
may be slightly
different.
--- jerome
Jerome,
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 -----
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
>
|
