Mocking references inside of a mock

2 posts, 0 answers
  1. Phil
    Phil avatar
    2 posts
    Member since:
    Jun 2012

    Posted 23 Dec 2014 Link to this post

    Trying to write tests for some legacy code and I have a question about mocking fields or other references inside a mock. In the code below, "Assert.IsNotNull(member.Rsa)" will fail because the mocked constructor of member hasn't created anything. Currently I've solved the problem by creating a separate mock and assigning to it, but is this really the best way to do this?
    var testChallengeData = new ChallengeData();
    testChallengeData.responseList = new Response[] {new Response(), new Response(), new Response()};
    var member = Mock.Create<Member>(Constructor.Mocked);
    var rsa = Mock.Create<Vendors.RSA>(Constructor.Mocked);
    Mock.SetupStatic(typeof (Settings), StaticConstructor.Mocked);
    Mock.Arrange(() => Settings.getBool(Arg.AnyString)).IgnoreInstance().Returns(false);
    Mock.Arrange(() => Settings.getInt(Arg.AnyString)).IgnoreInstance().Returns(3);
    Mock.Arrange(() => rsa.CurrUserStatus).IgnoreInstance().Returns(Vendors.AdaptiveAuthRef.UserStatus.UNVERIFIED).OccursOnce();
    Mock.Arrange(() => rsa.HasChallengeQuestions).IgnoreInstance().Returns(true).OccursNever();
    Mock.Arrange(() => member.challengeQuestions).IgnoreInstance().Returns(testChallengeData);
    Mock.Arrange(() => member.hasChallengeQuestions).CallOriginal();
    member.Rsa = rsa;
    Mock.Assert(() => Settings.getBool(Arg.AnyString), Occurs.Once());

  2. Stefan
    Stefan avatar
    198 posts

    Posted 24 Dec 2014 Link to this post

    Hello Phil,

    It all boils down to what is it that you're testing. Is "member.Rsa" part of the system under test, or is it a dependency that you want to mock out? If you want to test the logic that constructs and assigns member.Rsa, then that part should not be mocked, i.e. the constructor of Member should not be mocked in the test. If it is a dependency, then a mock should be manually assigned to it, but then it doesn't make sense to assert that it is not null. Such a check in this case asserts the function of the test code and not the system under test.

    Ideally, in a well-factored system, the system under test is a single class and all dependencies that need to be mocked are separate objects passed to it using some form of dependency injection. In such a system it is easy to see what is a dependency that needs to be mocked and which is the code that needs to be tested. When working with ill-factored code the distinction is less clear and the test code becomes a mix of arrangements, some with .CallOriginal(), some without. Nevertheless, the distinction is still there - there are parts of the class that are getting tested and parts that are logically dependencies and should be mocked out. Just be sure to know exactly which is which, so that you don't accidentally mock out the code that has to be tested and also that you don't assert the functionality of the mocks.


    Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

Back to Top