RE: [MO-java-dev] Nice Mocks ?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

So, you are saying my ContextListener should do things differently ?  I
don't have much experience with servlets and containers, so maybe my
understanding is not quite right.  Do you have experience doing
implementing ContextListeners ?  I do not and I based my tests on what I
found at
http://www.onjava.com/onjava/2003/01/08/examples/ContextListener.html,
which is a part of the article at
http://www.onjava.com/onjava/2003/01/08/tomcat4.html.

If you have a better way of doing this, I am all open to suggestions !

Thanks,
Fran=E7ois

PS: At the moment, I refactored my tests so that both cases are covered
in a single test.  So, the test is now named
testClosesDbAndRemovesAttributeFromContextOnDestruction().  Phhhew !

On Fri, 6 Jun 2003 01:48:33 +0100, "Tim Mackinnon"
<tim...@po...> said:
> I think there is probably a way to do what you want with the pieces that
> are
> there - or maybe you have some suggestion?
>=20
> The problem is that your test is very contrived - If closing requires
> both a
> removal of teamDb and a close, then its very artificial and rather
> confusing
> to test that behavior in two seperately isolated tests. Just don't do
> that.
>=20
> On the other hand I have seen cases were there is some metchAndReturn
> behavior that can be usefully put in setup so that other tests will get
> default values but in a few tests its strengthened to expectAndReturn to
> assert some specific behavior.
>=20
> Tim
>=20
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf Of
> > Francois Beausoleil
> > Sent: 04 June 2003 13:54
> > To: Tim Mackinnon; moc...@li...
> > Subject: RE: [MO-java-dev] Nice Mocks ?
> >
> >
> > Hello Tim,
> >
> > No, because when I execute the tests for initialization, I do not want
> > the Mock to report problems with the DB close() and removeAttribute()
> > methods.  I want it to report problems with the setAttribute() method a=
nd
> > DB instantiation.
> >
> > Let me reiterate.  The first test asserts that the "teamsdb" attribute
> > will be removed from the context.  The second one asserts that whatever
> > was in the "teamsdb" attribute receives a method call of "close".  Those
> > are two very different tests.  And they assert different things.  I wou=
ld
> > prefer that the first test ignore whatever happens with the actual obje=
ct
> > in the attribute, and that the second test ignore whatever happens with
> > the context.
> >
> > Thanks for your time,
> > Fran=E7ois
> >
> > On Wed, 4 Jun 2003 00:40:32 +0100, "Tim Mackinnon"
> > <tim...@po...> said:
> > > Is this an example of wanting to put in setUp() something like:
> > >
> > >
> > > setUp() {
> > >  servletContext =3D (ServletContext)mockServletContext.proxy();
> > >  ServletContextEvent event =3D new ServletContextEvent(servletContext=
);
> > >
> > >  mockServletContext.match("removeAttribute", C.eq("teamsdb"));
> > >
> > >  // OR
> > >  // mockServletContext.match("removeAttribute", C.ANY_ARGS);
> > > }
> > >
> > > The idea that you can override the match with an expect as in the fir=
st
> > > test
> > > and the second test will just get the match. In this case as that met=
hod
> > > is
> > > void its not matchAndReturn but this gives a nice symmetry for if the=
re
> > > was
> > > a method with a return value.
> > >
> > > I think we don't quite have this but its an easy one to do?
> > >
> > > I have often seen cases where we want default stuff in setup and can
> > > override specific exectations in the relevenat tests.
> > >
> > > Tim
> > >
> > > > -----Original Message-----
> > > > From: moc...@li...
> > > > [mailto:moc...@li...]On Behalf =
Of
> > > > Francois Beausoleil
> > > > Sent: 03 June 2003 19:02
> > > > To: moc...@li...
> > > > Subject: [MO-java-dev] Nice Mocks ?
> > > >
> > > >
> > > > Hello everyone,
> > > >
> > > > I started using 0.09 and I hit a snag.  The class under test is an
> > > > implementation of ContextListener.
> > > >
> > > > I am testing the destruction of the context.  I would like each of =
my
> > > > tests to test the minimum amount of code possible.  So, I
> > would like to
> > > > have a test that confirms that an attribute is removed from
> > the context,
> > > > and a second one to ensure that the DB is closed.  So, here's
> > the code at
> > > > the moment:
> > > >
> > > > public class TestContextListener extends TestCase {
> > > >     private final ContextListener contextListener =3D new
> > > >     ContextListener();
> > > >     private final Mock mockServletContext =3D new
> > > >     Mock(ServletContext.class);
> > > >
> > > >     public void testRemovesTeamDBOnDestruction() {
> > > >         mockServletContext.expect("removeAttribute", C.eq("teamsdb"=
));
> > > >         ServletContext servletContext =3D
> > > >                 (ServletContext)mockServletContext.proxy();
> > > >
> > > >         ServletContextEvent event =3D new
> > > >         ServletContextEvent(servletContext);
> > > >
> > > >         contextListener.contextDestroyed(event);
> > > >
> > > >         mockServletContext.verify();
> > > >     }
> > > >
> > > >     public void testClosesDBOnDestruction() {
> > > >         TeamDB db =3D new TeamDB(); // Need to check close with Mock
> > > >         mockServletContext.expectAndReturn("getAttribute", C.NO_ARG=
S,
> > > >         db);
> > > >
> > > >         ServletContext servletContext =3D
> > > >                 (ServletContext)mockServletContext.proxy();
> > > >
> > > >         ServletContextEvent event =3D new
> > > >         ServletContextEvent(servletContext);
> > > >
> > > >         contextListener.contextDestroyed(event);
> > > >
> > > >         mockServletContext.verify();
> > > >     }
> > > > }
> > > >
> > > > testRemovesTeamDBOnDestruction() passes, since I implemented things
> > > > correctly.  But testClosesDBOnDestruction() does not, as the
> > > > contextListener calls removeAttribute().  But I already know
> > that, since
> > > > the previous test asserts this very thing.  In my case, I
> > would like that
> > > > to not be an assertion failure.
> > > >
> > > > I could always join both tests and call it
> > > > "testRemovesTeamDB_And_ClosesDBOnDestruction()", but I prefer the t=
wo
> > > > simpler methods.
> > > >
> > > > Is there a way to make a Mock accept any method call that has
> > no return
> > > > value and just silently ignore it ?  I believe EasyMock
> > allowed something
> > > > like that and that it was called "Nice Mock".
> > > >
> > > > Thanks !
> > > > Francois
> > > > --
> > > >   Francois Beausoleil
> > > >   Developer of Java Gui Builder
> > > >   http://jgb.sourceforge.net/
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: eBay
> > > > Get office equipment for less on eBay!
> > > > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> > > > _______________________________________________
> > > > Mockobjects-java-dev mailing list
> > > > Moc...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > > >
> > > > ---
> > > > Incoming mail is certified Virus Free.
> > > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> > > >
> > > ---
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by:  Etnus, makers of TotalView, The b=
est
> > > thread debugger on the planet. Designed with thread debugging features
> > > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > >
> > --
> >   Francois Beausoleil
> >   Developer of Java Gui Builder
> >   http://jgb.sourceforge.net/
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.487 / Virus Database: 286 - Release Date: 01/06/2003
>=20
>=20
--
  Francois Beausoleil
  Developer of Java Gui Builder
  http://jgb.sourceforge.net/