From: Tim M. <tim...@po...> - 2003-06-06 00:44:42
|
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 |