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
When using .ReturnRecursiveFake() or .Fake.StaticMethods() on methods that return an unsupported mscorlib type, a TypeMockException is not thrown and instead null is silently returned, which later manifests as a NullReferenceException somewhere in the tested code which can be hard to track down. Such calls, when used with an unsupported type, should immediately throw a TypeMockException, just like .Fake.Instance<>() does.

Repro code:

public static Tuple<int> Create() { throw new NotImplementedException(); }

public void Test1()
   Isolate.WhenCalled(() => Create()).ReturnRecursiveFake();
asked by allon.guralnek (10.6k points)

2 Answers

0 votes
Hi Allon,

Thank you for informing us.

ReturnRecursiveFake() should indeed throw an exception because we use it to fake a single method's behavior and we expect it to behave accordingly.

Fake.StaticMethods() on the other hand, fakes an entire set of methods thus it will not allow to fake a class which contains a single method that returns an mscorlib type, which we believe is wrong. On top of that, this raises backward compatibility issues.
answered by alex (17k points)
0 votes
Yes, that makes sense, it would be difficult to use Fake.StaticMethods() otherwise.
answered by allon.guralnek (10.6k points)