Ниже вот тебе рабочий код синглтона, чтобы не придирался.

Придраться все равно есть к чему :)

Для начала надо понять, что мы хотим. Если цель написать максимально нетестируемый код, то это всегда можно сделать (и ты с этим замечательно справился). Если же цель сделать из нетестируемого кода тестируемый, то надо думать об изменениях.

А в этой теме ты мне, пожалуйста, покажи, как ты с internal сеттером к точке доступа к синглтону собираешься его заменить на мок в тесте.

  public interface IConfigRepository
  {
    int HowManyConfigItems(DateTime oldest);
  }

  public class ConfigRepository : IConfigRepository
  {
    private static IConfigRepository instance = null;
    public static IConfigRepository Instance
    {
      get
      {
        if (instance == null)
          instance = new ConfigRepository();
        return instance;
      }
      internal set
      {
        instance = value;
      }
    }
    private object userToken;
    private ConfigRepository()
    {
      userToken = UserRepository.Instance.GetUserToken(UserRepository.Instance.CurrentUser);
    }
    private IEnumerable GetConfigItems()
    {
      using (var conn = new SqlConnection(Properties.Resources.ConnectionString))
      {
        using (var dbContext = new MyDbContext(conn, contextOwnsConnection: true))
        {
          return dbContext.ConfigItems.Where(c => c.UserToken == userToken).ToList();
        }
      }
     }
    public virtual int HowManyConfigItems(DateTime oldest)
    {
      return GetConfigItems().Count(c => c.CreationDate >= oldest);
    }

Ну и, конечно, это абсолютно дурацкое решение делать сеттер в синглтоне internal - открываем ворота для всех подряд в сборке, мол, меняйте объект, когда хотите.

Ну с таким же успехом можно сказать, что дурацкое решение - это использование статических объектов в общем и синглтонов в частности.

Если тебе надо "закрыть ворота", то просто положи этот класс в отдельную сборку. Ну или извращайся с рефлекшенами или с хот-патчами.