From: Paul B. <Pau...@vi...> - 2004-07-06 22:39:42
|
Not entirely sure what you mean, but methods A-E are on the object I = want to test, so I can't replace them. And it's not that I want to set = expectations for methods A-E, it's that they generate calls to my Mock = object, which I have to account for when I verify method X later. Example: DynamicMock m =3D new DynamicMock(typeof(IMyInterface)); IMyInterface itf =3D (IMyInterface)m.MockInstance; MyInterestingObject foo =3D new MyInterestingObject(itf); // Set up for the real test. foo.A(); // calls itf.helper(); foo.B(); // calls itf.helper(); foo.C(); // calls itf.helper(); foo.D(); // calls itf.helper(); foo.E(); // calls itf.helper(); // I'd like to clear all the expectation counters built up on itf at = this point. m.Expect("xHelper"); foo.X(); // calls itf.helper(); m.Verify(); If the helper counter isn't cleared, I'm expecting 1 call, and the mock = knows of 6, which results in a test failure. Obviously, in this case, = it would be easy to handle this sample case, but as my tests get more = and more complicated, it gets harder and harder. As I mentioned, what = I'm looking for is more of a convinence than anything else. Thanks! :) -----Original Message----- From: Steve Freeman [mailto:st...@m3...] Sent: Tuesday, July 06, 2004 2:53 PM To: Paul Brousseau Cc: Owen Rogers; nmo...@li... Subject: Re: [Nmock-general] RE: NMock Could you stub methods A..E, rather than setting expectations on them? S Paul Brousseau wrote: > It's not so much a problem as a possible inconvinience at times. I > think my sample below didn't properly set up the situation. Let's > say that I have method X that I want to test, but to get to the right > state, I have to call methods A, B, C, D, and E, each of which result > in calls to the Mock object. It would be easier for me to not have > to worry about counting the various method calls in that setup stage. > If I could wipe out my expectations, then I would only have to check > the stuff that goes along with method X. So there's nothing wrong > with calling Verify multiple times, but I'd like not to have to think > about verifying the results of methods A-E (say, because I've already > verified that they work elsewhere). >=20 |