Recursive mocks - assertions not working correctly

[Isaac Abraham]

public interface IFoo
{
    IBar GetBar(string x);
}
public interface IBar
{
    void DoBar(int x);
}

public class Tests
{
    [Fact]
    public void First()
    {
        var foo = Mock.Create<IFoo>();

        foo.GetBar("a").DoBar(1);

        Mock.Assert(() => foo.GetBar("b").DoBar(1));
    }
}

The above test passes, although it should fail.

[Stefan]

Hello Isaac,

Thank you for contacting us.

This is, in fact, expected behavior. When a function is not arranged, it falls back to its default behavior as given by the mock behavior. For RecursiveLoose, the default is to return the same mock object, regardless of function arguments. For more finely-grained control over return values you can always use explicit arrangements.

Is there a particular reason for you to prefer that functions on RecursiveLoose mocks return different mock objects for different arguments?

Regards,
Stefan
Telerik

[Isaac Abraham]

Hi Stefan

Why do I want this? Because of the exact example I showed :-) That assertion should not return true. I understand why it does return true - because you're asserting the "final" mock object call - whereas I hoped that Mock.Assert(() => { }) would assert every mockable call in the expression.

[Stefan]

Hi Isaac,

Ah, now I understand. You'd like Mock.Assert to assert all sub-expressions, not just the final one. If we were to implement it like this, however, if you really wanted to assert just the final bit, then you'd have to store it in a temporary variable outside the assert call - a possible nuisance in the other direction. Moreover, reimplementing Assert like you suggest will undoubtedly break existing tests. Given the circumstances I cannot say that your suggestion is a clear win. This feature starts out with -100 points and will have to climb out of the pit, if we are to consider it :)

Regards,
Stefan
Telerik

[Isaac Abraham]

Stefan,

Actually you wouldn't need to break out the final mocked object - you could pass in Args.AnyString etc. etc. for the earlier arguments in the chain that you are not bothered about :-)

Breaking changes - yes, that would be an issue. Perhaps an optional  argument that could be passed in when creating the mocking container etc. that could specify what behaviour you would like to have in this situation?

With either of those suggestions, I think that this shouldn't be a -100 :-)

[Kaloyan]

Hi Isaac,

This seems reasonable.

Please, add it into our Ideas and Feedback portal in order to be voted for future implementation.

Thank you in advance.

Regards,
Kaloyan
Telerik