From: Jeff M. <je...@mk...> - 2002-04-19 09:06:05
|
I spent sometime yesterday, working through the mail facade stuff, gradually implementing the bits I needed (tiny tiny steps), and the processes worked quite well. I don't know whether it would have worked so well if I'd of had to write a test as well. There's great temptation then as well to write tests for methods which you personally don't need, and end up with mocks that aren't built from usage but from planning. Maybe that stuff just need a bit more refactoring. On Thu, 2002-04-18 at 23:40, Steve Freeman wrote: > From: "Jeff Martin" <je...@mk...> > > On Wed, 2002-04-17 at 22:43, Steve Freeman wrote: > > > > Actually the general consensus is that mocks don't need tests. The > > > idea > > > > is to keep them really simply so there's nothing in them worth > > > testing. > > > > That's the good thing about the expectation stuff. That's got > tests > > > and > > > > that's the bit that doe's the work. > > > > > > Actually, I'm beginning to turn on this one. For long-term mocks, > such > > > as in the library, it's sometimes hard to tell what they do, and it > > > might not be a bad idea to write the unit tests for documentation -- > > > rather than more javadoc. > > > Hmm, not sure, shouldn't the code be as self explanatory as possible. > > Most of the the mocks should be pretty simple. > > I know this argument, since I made it a lot, but now I find that I'm > coming back to some of the more complex mocks (such as the sql library) > and can't remember what they do. Unfortunately, some of the standard > interfaces are so bloated that the associated mocks are likely to be > complex. > > I wouldn't make it mandatory, but would like to encourage it. > > Steve > > > > > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev -- |