This is a migrated thread and some comments may be shown as answers.

Recursive mocks - assertions not working correctly

5 Answers 26 Views
JustMock Free Edition
This is a migrated thread and some comments may be shown as answers.
Isaac Abraham
Top achievements
Rank 1
Isaac Abraham asked on 29 Nov 2013, 03:22 PM
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.

5 Answers, 1 is accepted

Sort by
0
Stefan
Telerik team
answered on 03 Dec 2013, 12:55 PM
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
Share what you think about JustTrace & JustMock with us, so we can become even better! You can use the built-in feedback tool inside JustTrace, our forums, or our JustTrace or JustMock portals.
0
Isaac Abraham
Top achievements
Rank 1
answered on 03 Dec 2013, 01:45 PM
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.
0
Stefan
Telerik team
answered on 03 Dec 2013, 02:35 PM
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
Share what you think about JustTrace & JustMock with us, so we can become even better! You can use the built-in feedback tool inside JustTrace, our forums, or our JustTrace or JustMock portals.
0
Isaac Abraham
Top achievements
Rank 1
answered on 03 Dec 2013, 02:38 PM
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 :-)
0
Kaloyan
Telerik team
answered on 06 Dec 2013, 12:14 PM
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
Share what you think about JustTrace & JustMock with us, so we can become even better! You can use the built-in feedback tool inside JustTrace, our forums, or our JustTrace or JustMock portals.
Tags
JustMock Free Edition
Asked by
Isaac Abraham
Top achievements
Rank 1
Answers by
Stefan
Telerik team
Isaac Abraham
Top achievements
Rank 1
Kaloyan
Telerik team
Share this question
or