How to Shim long external dependency with ConcurrentDictionary (C#) via Microsoft Fakes?

Question

In code I need to test was found such external dependency:

var something = GConfig.SConfig[Type.ServiceType1].Names;

Code of this part is like this:

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;

namespace Class
{
    public sealed class GConfig
    {

        public ConcurrentDictionary<Type, GConfigIt> SConfig { get; set; }

        public GConfig()
        {
            SConfig = new ConcurrentDictionary<Type, GConfigIt>();
            throw new InvalidOperationException("Error");
        }
    }

    public enum Type
    {
        ServiceType1,
        ServiceType2
    }

    public class GConfigIt
    {
        public List<string> Names { get; set; }

        public GConfigIt()
        {
            Names = new List<string>();
        }
    }
}

I need to shim that dependency, but on my own I can't find full solution, only partly:

For GConfigIt (and shimming Names): Fakes.ShimGConfigIt.AllInstances.NamesGet

For shimming SConfig: Fakes.ShimGConfig.AllInstances.SConfigGet

But I can't find connection, how to shim it fully.

P.S. I'm only a tester and can't change existing code. For making a change I need to convince developers to do it (i.e. extra interface for GConfig), but they must sure that it's not a change just for "easy testing" or "testing for testing" and they really need to do it.

Answer 1

Okay, so you are actually on the right track. You begin with Fakes.ShimGConfig.AllInstances.SConfigGet, and once that works, you need to shim the dictionary.

Probably something like Fakes.ShimConcurrentDictionary.AllInstances.ItemGetType which you can make return whatever GConfigIt you want, probably a stub.

You can either set the property of said stub or do what you were doing before for names.

I'm assuming the concurrent dictionary can be shimmed; If not, you still aren't stuck. Simply shim your SConfigGet to return a stub of SConfigGet, into which you can enter valid values. This might even be better than the other way, since you assume less about the implementation.