From: Nat P. <nat...@b1...> - 2003-12-17 17:02:22
|
It is possible to do that in the current (non-dynamic) API. Just turn off immediate verification on your expectation objects. But do you really want to? It's much harder to work out what went wrong after the fact because all the state that existed when the error occurred has been lost. If the mock fails as soon as it detects an error it can generate better error messages and you can make the debugger break into the program when it fails, so letting you examine your live objects to find the error. Cheers, Nat. On Wed, 2003-12-17 at 16:37, J. Xue wrote: > Quoting Nat Pryce <nat...@b1...>: > > > ClassUnderTest would call an interface to perform unmarshalling. It > > wouldn't care if the implementation of the interface was an adapter or a > > direct implementation. Whichever approach you take (adapter or mocking > > castor), you'd put the mock unmarshaller into your own test package. > > There's no need to touch the castor packages. > > Yeah, it seems that an adapter is the most viable way so far. I did have some > other thoughts while we were exchanging these messages, though. Is it possible > to relax the expectation semantics so that expectations wouldn't have to be set > *before* the "actuals" happen. Wouldn't it be more flexible if expectations > can be set at any time before verification, while actual cases are only > recorded as they happen? Then only at verification time they would be compared > against each other. > > --J.X. > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Mockobjects-java-users mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users |