From: Tim M. <tim...@po...> - 2003-05-18 20:13:38
|
Vincent - this example makes no sense at all to me? You probably should have showed the tests that go along with this so we could understand what you are saying. This said, I would tentatively advocate a reset - I thing you are mirroring what Joe said previously in that it can be a pain if you have used setUp to configure a mock and then later just want to do something totally different for one case. I have seen this and so would agree with this change. HOWEVER - YOU ADDED RESET WITHOUT UPDATING THE TESTS!!!! SHAME ON YOU!!!! Part of the reason for rewriting the mock library was to get better test coverage... I would like to get Steve's opinion as well, he is good at enforcing a clean API. Please can we confer on some of these things to try and prevent a massive API buildup. I also want to insist that we don't put comments in the code like you just did. Please read Martin Fowlers refactoring book - rather than have: /** * Resets all expected calls and expected matches. */ Call the method something more explicit in the first place, then we you are using the method in your code, it also won't need a comment above it either - I would suggest: resetAllMatchesAndExpectations. Then you don't need a comment! Tim > -----Original Message----- > From: moc...@li... > [mailto:moc...@li...]On Behalf Of > Vincent Massol > Sent: 17 May 2003 19:55 > To: 'Mockobjects-Java-Dev' > Subject: [MO-java-dev] Resetting dyna mocks - new reset() method > > > Hi, > > I have a requirement for introducing a reset on dyna mocks so that they > can be reused. > > Here's the use case: > > I am setting up a Mock InitialContext factory with: > > NamingManager.setInitialContextFactoryBuilder( > new InitialContextFactoryBuilder() { > public InitialContextFactory > createInitialContextFactory( > Hashtable environment) throws NamingException > { > return new InitialContextFactory() { > public Context getInitialContext(Hashtable env) > throws NamingException > { > // Return the mock context here > return context; > } > }; > } > }); > > The setInitialContextFactoryBuilder() is a static method and can only be > called *ONCE* in the lifetime of the JVM. Which means that it will be > shared between testXXX() tests. Thus the InitialContext mock (in "return > context") also has to be static. > > The second step is to define expectations on the context mock lookup() > method so that we can return mocks. By doing this we are tying the > static context mock with the other per-testXXX() mocks... > > ... which means that if we have 2 test methods setting expectations on > lookup() with the same lookup name, the second test fails.... > > I believe this is a valid use case and that in order to support this use > case, we need to introduce a reset() method in the dynamock Mock class > to rest all expectations. > > I've just committed the patch to support this reset method. If you think > we should not have a reset() method, I can always remove it. > > Thanks > -Vincent > > > > ------------------------------------------------------- > This SF.net email is sponsored by: If flattening out C++ or Java > code to make your application fit in a relational database is painful, > don't do it! Check out ObjectStore. Now part of Progress Software. > http://www.objectstore.net/sourceforge > _______________________________________________ > 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.476 / Virus Database: 273 - Release Date: 24/04/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003 |