mockobjects-java-dev

[MO-java-dev] Nice Mocks ?

[Francois B. <fb...@us...>]

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 = new
    ContextListener();
    private final Mock mockServletContext = new
    Mock(ServletContext.class);

    public void testRemovesTeamDBOnDestruction() {
        mockServletContext.expect("removeAttribute", C.eq("teamsdb"));
        ServletContext servletContext =
                (ServletContext)mockServletContext.proxy();

        ServletContextEvent event = new
        ServletContextEvent(servletContext);

        contextListener.contextDestroyed(event);

        mockServletContext.verify();
    }

    public void testClosesDBOnDestruction() {
        TeamDB db = new TeamDB(); // Need to check close with Mock
        mockServletContext.expectAndReturn("getAttribute", C.NO_ARGS,
        db);

        ServletContext servletContext =
                (ServletContext)mockServletContext.proxy();

        ServletContextEvent event = 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 two
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/

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

[Tim M. <tim...@po...>]

Is this an example of wanting to put in setUp() something like:


setUp() {
 servletContext = (ServletContext)mockServletContext.proxy();
 ServletContextEvent event = 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 first test
and the second test will just get the match. In this case as that method is
void its not matchAndReturn but this gives a nice symmetry for if there 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 = new
>     ContextListener();
>     private final Mock mockServletContext = new
>     Mock(ServletContext.class);
>
>     public void testRemovesTeamDBOnDestruction() {
>         mockServletContext.expect("removeAttribute", C.eq("teamsdb"));
>         ServletContext servletContext =
>                 (ServletContext)mockServletContext.proxy();
>
>         ServletContextEvent event = new
>         ServletContextEvent(servletContext);
>
>         contextListener.contextDestroyed(event);
>
>         mockServletContext.verify();
>     }
>
>     public void testClosesDBOnDestruction() {
>         TeamDB db = new TeamDB(); // Need to check close with Mock
>         mockServletContext.expectAndReturn("getAttribute", C.NO_ARGS,
>         db);
>
>         ServletContext servletContext =
>                 (ServletContext)mockServletContext.proxy();
>
>         ServletContextEvent event = 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 two
> 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

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

[Francois B. <fb...@us...>]

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 and
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 would
prefer that the first test ignore whatever happens with the actual object
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:
>=20
>=20
> setUp() {
>  servletContext =3D (ServletContext)mockServletContext.proxy();
>  ServletContextEvent event =3D new ServletContextEvent(servletContext);
>=20
>  mockServletContext.match("removeAttribute", C.eq("teamsdb"));
>=20
>  // OR
>  // mockServletContext.match("removeAttribute", C.ANY_ARGS);
> }
>=20
> The idea that you can override the match with an expect as in the first
> test
> and the second test will just get the match. In this case as that method
> is
> void its not matchAndReturn but this gives a nice symmetry for if there
> was
> a method with a return value.
>=20
> I think we don't quite have this but its an easy one to do?
>=20
> I have often seen cases where we want default stuff in setup and can
> override specific exectations in the relevenat tests.
>=20
> Tim
>=20
> > -----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_ARGS,
> >         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 th=
at
> > to not be an assertion failure.
> >
> > I could always join both tests and call it
> > "testRemovesTeamDB_And_ClosesDBOnDestruction()", but I prefer the two
> > 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 somethi=
ng
> > 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
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
--
  Francois Beausoleil
  Developer of Java Gui Builder
  http://jgb.sourceforge.net/

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

[Tim M. <tim...@po...>]

I think there is probably a way to do what you want with the pieces that are
there - or maybe you have some suggestion?

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.

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.

Tim

> -----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 and
> 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 would
> prefer that the first test ignore whatever happens with the actual object
> in the attribute, and that the second test ignore whatever happens with
> the context.
>
> Thanks for your time,
> François
>
> 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 = (ServletContext)mockServletContext.proxy();
> >  ServletContextEvent event = 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 first
> > test
> > and the second test will just get the match. In this case as that method
> > is
> > void its not matchAndReturn but this gives a nice symmetry for if there
> > 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 = new
> > >     ContextListener();
> > >     private final Mock mockServletContext = new
> > >     Mock(ServletContext.class);
> > >
> > >     public void testRemovesTeamDBOnDestruction() {
> > >         mockServletContext.expect("removeAttribute", C.eq("teamsdb"));
> > >         ServletContext servletContext =
> > >                 (ServletContext)mockServletContext.proxy();
> > >
> > >         ServletContextEvent event = new
> > >         ServletContextEvent(servletContext);
> > >
> > >         contextListener.contextDestroyed(event);
> > >
> > >         mockServletContext.verify();
> > >     }
> > >
> > >     public void testClosesDBOnDestruction() {
> > >         TeamDB db = new TeamDB(); // Need to check close with Mock
> > >         mockServletContext.expectAndReturn("getAttribute", C.NO_ARGS,
> > >         db);
> > >
> > >         ServletContext servletContext =
> > >                 (ServletContext)mockServletContext.proxy();
> > >
> > >         ServletContextEvent event = 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 two
> > > 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 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
> >
> --
>   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

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

[Francois B. <fb...@us...>]

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/