chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
Ask a question
The Unit Testing Company
Development Resources
Knowledge Base
Welcome to Typemock Community! Here you can ask and receive answers from other community members. If you liked or disliked an answer or thread: react with an up- or downvote.

Related questions

RepeatAlways causes method overloading to fail

0 votes
I had some mocking code like this: 
recorder.ExpectAndReturn(x.GetRenewalPrice(0), rp).RepeatAlways();
recorder.ExpectAndReturn(x.GetRenewalPrice(0, 0), drp).RepeatAlways();

Unfortunately, TypeMock is returning drp for both versions of the method call. I confirmed the problem by reversing the lines...thereafter, rp was returned from both methods.

It seems that the RepeatAlways() is not recognizing the method signature as a distinguishing characteristic. This seems like a bug.

To work around the problem, I did this: 
recorder.VerifyMode = VerifyMode.PassIfNotCalled;
recorder.ExpectAndReturn(x.GetRenewalPrice(0), rp);
recorder.ExpectAndReturn(x.GetRenewalPrice(0, 0), drp);

I'm using Isolator v4.2.3.0, VS2005, and .NET2.0.

Hope this helps!
asked by dougclutter
Report User
 (3.5k points)

3 Answers

0 votes
I found that my previously posted work-around doesn't work as a complete replacement for RepeatAlways().

A little more digging led me to this: 
recorder.ExpectAndReturn(x.GetRenewalPrice(0), rp).RepeatAlways().WhenArgumentsMatch(a);
recorder.ExpectAndReturn(x.GetRenewalPrice(0, 0), drp).RepeatAlways().WhenArgumentsMatch(a, b);

I'm betting this is the "right" way to do it...but I still think the code should work without WhenArgumentsMatch.
answered by dougclutter
Report User
 (3.5k points)
0 votes
Hi,

It does look strange - what you are after is stubbing the calls, not using conditional mocking. We'll take a look at it.
answered by gilz
Report User
 (14.5k points)
0 votes
After further investigation here are the results.

First, as you stated, this is the "right" way to do it.

Isolator has a limitation with overloads, and will work with the first expectaion set on the overloaded method, as you have witnessed. The one caveat is that conditional mocking (i.e., using the WhenArgumentMatch) allows identifying the correct overload, and again, you've come to that conclusion.

Supporting method overloads is on our planned feature list, so we'll get there.
answered by gilz
Report User
 (14.5k points)
...

Products

Help

Company

Community

Contact

Typemock Store (US toll FREE 866–895–4680). Copyright © 2006 Typemock Inc. All rights reserved. Terms of Use.