Recursive mocks - assertions not working correctly

6 posts, 0 answers
  1. Isaac Abraham
    Isaac Abraham avatar
    21 posts
    Member since:
    Sep 2009

    Posted 29 Nov 2013 Link to this post

    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.
  2. Stefan
    Admin
    Stefan avatar
    198 posts

    Posted 03 Dec 2013 Link to this post

    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.
  3. DevCraft R3 2016 release webinar banner
  4. Isaac Abraham
    Isaac Abraham avatar
    21 posts
    Member since:
    Sep 2009

    Posted 03 Dec 2013 Link to this post

    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.
  5. Stefan
    Admin
    Stefan avatar
    198 posts

    Posted 03 Dec 2013 Link to this post

    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.
  6. Isaac Abraham
    Isaac Abraham avatar
    21 posts
    Member since:
    Sep 2009

    Posted 03 Dec 2013 Link to this post

    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 :-)
  7. Kaloyan
    Admin
    Kaloyan avatar
    872 posts

    Posted 06 Dec 2013 Link to this post

    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.
Back to Top
DevCraft R3 2016 release webinar banner