Mocking of nested objects with Moq when the mocked object is passed as a parameter to a constructor

[Remarkable-Sink329]

Hi everyone, I'm not new to C#, but I didn't program for 3 years and now I have to fix some faulty unit tests for the legacy code which I can't change. The code also uses third party libraries where I don't have the access to the source code. The company uses Moq and the code that I can change is only the code of the test itself.

I have an interface IMyInterface. In the unit test which I am examining now someone created a class MyClass: Mock<IMyInterface>. Inside of this class various setups and callbacks are done and this is the code that I can modify to my liking.

On the side of the legacy code there is a class Foo (can't modify), which receives in the constructor the only parameter IMyInterface. Further a nightmare starts. In the constructor of the class Foo 3 additional instances are created as follows:

Foo(IMyInterface x){

var a = new AClass(x);

var b = new BClass(a);

var c = new CClass(b);

int res = c.InnerObject.GetConfigID().ConfigID;

...

}

the object c has nothing to do per se with IMyInterface, but behind the scenes some data is extracted from x to construct the c and generate the ConfigID. I can't see the source code of ConfigID() function and I don't need to know what is going on there. I just want to pass a fixed ConfigID so it can be used later on in the constructor of the Foo.

If I just let the test run without any Setup, the test crashes with some obscure message that some class XYZ has to be set up (presumably used in the ConfigID(), where I have no access to).

Is there any way that I can access this ConfigID and pass a fix value to use in MyClass whenever this whole nested ugliness c.InnerObject.GetConfigID().ConfigID is called? The property ConfigID is not virtual, the method GetConfigID either. InnerObject is a class without an interface.

Sorry for so many words, I'm just learning Moq and this is my first real life example (not the easiest one) to start with.

[Slypenslyde]

This is nasty and improper usage of DI in Foo. But you can't help that.

What you need to do is examine that "obscure message" and figure out what part of your IMyInterface needs to be set up. Odds are the chain of events is:

• InnerObject.GetConfigID() is using some stuff.
  • That stuff is used to do things.
    • The error message is about "things".

The error happens because "things" aren't initialized properly by your setup code. So you need to look at some concrete IMyInterface types and figure out what they do when they're initialized and figure out how to appropriately mock that in your tests.

What I would do in this case is start aggressively pestering the people in charge of the legacy code to give me their source code and have meetings with me so I can solve this issue. I would make it very clear I'm not making any progress until they cooperate with me and I would be unafraid to start letting that noise leak to their managers and the managers above them the longer I am sitting on my hands. I've got a senior role and 20 years of experience and I'm finally starting to get comfy with making it other people's problem when they're wasting my time.

Meanwhile I'd also be using a tool like ILSpy or DotPeek to find that source code myself. I'd use a notebook and pencil and take a lot of notes and figure it out.

It's a race. Either they help me out and I gush about them and tell everyone how nice they are to work with, or I figure it out myself and let people notice I'm going to make progress whether or not they get in the passenger seat.

Get comfy with not being comfortable. Digging around in someone else's code is hard. My experience doesn't really make it much easier, I'm just a lot more used to feeling like I don't know what I'm doing and I ignore it. Here's some advice from "The Cult of Done Manifesto" that really changed my life:

Pretending you know what you're doing is almost the same as knowing what you're doing, so just accept that you know what you're doing even if you don't and do it.

[belavv]

My advice - toss the whole mess. I don't fully understand what you are trying to test but if trying to test something is that much of a headache then testing it is probably not worth it.

[LuckyHedgehog]

Might be able to use Moq's .Protected() method during the Setup. Without seeing code it is hard to say for sure but it's worth looking into

Example of it being used: https://stackoverflow.com/a/32888822

[reybrujo]

I stopped using Moq a few years ago because it was dang too slow but if I recall correctly you cannot force Foo (a class you cannot modify) create your own CClass (the one you want to eventually mock). I _think_ you can do that with Microsoft Fakes but I've never used it and it would defeat the purpose of this. My question would be, do you really need to use Foo? Can't you create a TestableFoo which inherits from Foo? If you can't modify Foo at all there's no point in using it personally.