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
I just wrote a post on my blog experimenting with an implementation of an extension method for the Mock.ExpectedCall() method which is 100% typesafe (my primary goal was to make it resilient to method name refactorings), by using a trick the ASP.NET MVC framework has pioneered. It uses lambda syntax and evaluates it as an expression tree to pick out the method name, and looks like this in use:

Mock fooMock = MockManager.Mock<Foo>();
fooMock.ExpectCall<Foo>(f => f.Bar());

It does have a few limitations (only works for public non-static methods), but I think it has the potential to be a very useful feature, especially for those who don't have the Pro/Enterprise editions with Natural Mocks :wink:

Similar overloads could be implemented for several other Mock members aswell.

You can find a detailed discussion + source code for the extension method on my blog :)
asked by Fredrik (1.1k points)

2 Answers

0 votes
Hi Frederik,

Thanks for the nice post. It's always exciting to see how the users of our product can build on the product we built here. It also gives the team here ideas how to improve Typemock for the next releases.

I'm curious - did you test your wrapper in how it impacts the performance of running the tests? (if that's an issue at all)

Keep up the good work!

PS -
and do ask the Powers That Be to pay for the Enterprise license - you want regret it! :D
answered by gilz (14.5k points)
0 votes
I think I came up with a better implementation:

TypeMock: How to Make Reflective Mocks More Natural
answered by paulo.morgado (11k points)