6 Comments

  • Brian, yes, that would solve it.
    since we are invoking the method as part of our internal process, we can only send in values that are legal for the code in themethod (we have no way of knowing if null is valid or not)

  • Brian, can you post the complete test and exception message, or drop an email with the details to support at typemock.com? It seems like your code should work - the null value should not cause an issue.

  • @Brian, WhenCalled() doesn't actually run the methods logic and so it shouldn't throw any exception. If you define a .CallOriginal() behavior then you will get an exception when the method is called.

    @Roy,
    You can add the Array/IEnumerator behavior - allowing developers to switch between either in the production code without needing to change the test.

    So a: WhenCalled(()=>fake[5].Name).WillReturn("Roy");

    will work regardless of the access method used in the production code (all these will pass)

    for (int i = 0 ; i i.Name=="Roy).Count();

  • Hello,

    Doron, Eli, I will double-check this and get back to you. Last I remember, if I did:

    Isolate.WhenCalled(() => o.Call(null, null)).WillReturn(1);

    I got an exception thrown. Will double-check and post something on the forum. Consequently, I thought I already did, but I can't find it, so I'll post again.

    Thanks.

  • Not lazy web...just over-worked folks who have no time to surf lately!

  • Hmm, I'm not getting the same result. Isolate.WhenCalled() is working. Don't know what it was related to originally (maybe some other error), but if I get it again, will let you know. Thanks all for the guidance.

Comments have been disabled for this content.