Mocking references inside of a mock

[Phil]

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;

Assert.IsNotNull(member.Rsa);
Assert.IsTrue(member.hasChallengeQuestions);
rsa.Assert();
Mock.Assert(() => Settings.getBool(Arg.AnyString), Occurs.Once());

[Stefan]

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.

Regards,
Stefan
Telerik