RecordExpectations.FailWhenCalled feels strange

I can kind of see the logic of why you're getting that, though I see that you wanted a "do what I mean, not what I say" sort of thing here, right? You're chaining calls together, so it expects the call to Request and will fail if you call AppRelativeCurrentExectionFilePath on that.

I wonder if that's technically what's going on behind the scenes when you mock a chained call, too. Like, if it's actually creating two mocks for you in a row - the Request, then the AppRelativeCurrentExecutionFilePath - but you never notice it because that's how you call it from your code.

I think it should have done what you meant, not what you said. Like maybe when it sets up the internal Request mock (assuming that's what's happening) that it should also set it so Verify will pass if it's not called.

Sounds like an issue for Typemock folk!

I understand what's going on under the covers, but looking at the written test it's not obvious.

I rarelly use mock chaining because of this, and, in this particular case, I was only using that member of HttpRequest, so I changed to:

recorder.FailWhenCalled(httpContext.Request);

hi,

Going back and rereading this, I must say that you are right.

In general Chaining is a more complex concept and sometime the meaning of what the user meant to do is not that clear.
I still think however that what you see is more on the side of a bug.

:?: What would you expect to happen if during your test (when using the original FailWhenCalled statement) you would have issued the following call:

httpContext.Request;

I would expect only to fail if and only if the recorded failing call would be issued. I would this to pass.

// Insulator 4.2
    public class TestedClass1
    {
        public IDictionary<string, object> Dictionary
        {
            get { throw new NotImplementedException(); }
        }

        public object Method(bool cond)
        {
            if (cond)
            {
                return Dictionary["true"];
            }
            else
            {
                return Dictionary["false"];
            }
        }
    }

    [TestClass]
    [ClearMocks]
    public class UnitTest1
    {
        [TestMethod]
        [VerifyMocks]
        public void TestMethod1()
        {
            object trueObject = new object();
            object falseObject = new object();

            TestedClass1 target = RecorderManager.CreateMockedObject<TestedClass1>();

            using (RecordExpectations recorder = RecorderManager.StartRecording())
            {
                recorder.DefaultBehavior.CheckArguments();

                recorder.ExpectAndReturn(target.Dictionary["true"], trueObject).Repeat(2);
                recorder.FailWhenCalled(target.Dictionary["false"]);
            }

            object value;
            value = target.Method(true);
            Assert.AreEqual(trueObject, value);

            value = target.Method(true);
            value = target.Dictionary;
        }
    }

But that's tricky. Something like System.Web.HttpContext.Current could change from one call to another.

Probably a setting to say that all common chains should or should not return the same mocked instance.