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
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.
0 votes
Hi,

TypeMock is a great product.

Nevertheless there are some APIs that were designed during development process but would have been more elaborate if designed completely ahead.
E.g. the ExpectXxx methods, esp. the ExpectXxxAlways methods.
First of all there are some methods missing, like ExpectAndReturnAlways.
But I would not propose to add those missing methods.
A better way is to add a bool parameter to each ExpectXxx that indicates "Always".

In my opinion the easiest way would be to give the parameter TimesToRun an additional meaning: -1 = run zero or any times.
That would make the ExpectXxxAlways methods obsolete,
the API gets slimmer,
every method can run "always" and
I think the implementation is not very complex.
asked by mknaup (8.5k points)

3 Answers

0 votes
Hi,

TypeMock is a great product.

Thanks.

E.g. the ExpectXxx methods, esp. the ExpectXxxAlways methods.
First of all there are some methods missing, like ExpectAndReturnAlways.
But I would not propose to add those missing methods.
A better way is to add a bool parameter to each ExpectXxx that indicates "Always".

In my opinion the easiest way would be to give the parameter TimesToRun an additional meaning: -1 = run zero or any times.
That would make the ExpectXxxAlways methods obsolete,
the API gets slimmer,
every method can run "always" and
I think the implementation is not very complex.


Thanks for the suggestion, we will take it into account.
There is a method AlwaysReturn that does what you want.
We could easily implement your suggestion, but then it will make reading the code a bit complex, instead of knowing the the method will AlwaysReturn a value, we have to see that -1 is a special value parameter. This becomes more complicated when you have a default value and specific values (i.e. using AlwaysReturn and ExpectAndReturn together) as the code will look the same even though the behaviour is different.

Of course I am sure that we can refine and get better API's. If you or anyone have other suggestions, please continue this topic.
answered by scott (32k points)
0 votes
Hi Scott,
There is a method AlwaysReturn that does what you want.
We could easily implement your suggestion, but then it will make reading the code a bit complex, instead of knowing the the method will AlwaysReturn a value, we have to see that -1 is a special value parameter. This becomes more complicated when you have a default value and specific values (i.e. using AlwaysReturn and ExpectAndReturn together) as the code will look the same even though the behaviour is different.


I was looking for something like ExpectAndReturnAlways but for a better reading and understanding you called it AlwaysReturn . As most of the methods start with "Expect" I missed that method... Sorry!

On the other hand ExpectGetAlways suggests that a call (at least one) to the getter is expected though Verify is true even if the getter was not called (as for all those "ExpectxxxAlways" methods). Shouldn't it be named AlwaysGet?

Now, if the parameter -1 is confusing (I agree to that) what about an enum value?
E.g.: ExpectGet("Name", Expect.Always)
or ExpectGet("Name", Expect.UnlimmitedCalls)
or similar...

Does anybody have more/other suggestions?
answered by mknaup (8.5k points)
0 votes
Michael,
:idea: TypeMock.NET version 3.5 now supports Natural TypeMocks™
Natural TypeMocks™ are Strongly Typed and thus supports Compile Time Checks and Refactoring.
This may seem more natural to use
answered by scott (32k points)
...