Как издеваться над статическим синглтоном?

Синглтоны не подходят для тестирования, потому что их очень сложно изменить. Было бы намного лучше использовать Внедрение зависимостей для внедрения экземпляра ISomeInterface в ваши классы потребления:

public class MyClass
{
    private readonly ISomeInterface dependency;

    public MyClass(ISomeInterface dependency)
    {
        if(dependency == null)
        {
            throw new ArgumentNullException("dependency");
        }

        this.dependency = dependency;
    }

    // use this.dependency in other members
}

Обратите внимание, как Guard Claus вместе с ключевым словом readonly гарантирует, что экземпляр ISomeInterface всегда будет доступен.

Это позволит вам использовать Rhino Mocks или другую динамическую имитационную библиотеку для внедрения тестовых двойников ISomeInterface в потребляющие классы.

Обескураженный подобными темами, мне потребовалось некоторое время, чтобы заметить, что синглтоны не так уж и сложно высмеять. В конце концов, почему мы используем C #?

Просто используйте Reflection.

С предоставленным образцом кода вам необходимо убедиться, что статический конструктор вызывается перед установкой статического поля для фиктивного объекта. В противном случае он может перезаписать ваш фиктивный объект. Просто вызовите на синглтоне что-нибудь, что не действует, перед настройкой теста.

ISomeInterface unused = Singleton.Instance();

System.Reflection.FieldInfo instance = typeof(Example1).GetField("_instance", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);

Mock<ISomeInterface> mockSingleton = new Mock<ISomeInterface>();
instance.SetValue(null, mockSingleton.Object);

Я предоставил код для насмешек с Moq, но я думаю, что Rhino Mocks очень похож.

Вот подход с низким уровнем взаимодействия, который использует делегат, который может быть установлен изначально и изменен во время выполнения. Лучше пояснить это на примере (в частности, насмехаясь над DateTime.Now):

http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/11/09/systemtime-versus-isystemclock-dependencies-revisited.aspx.

Пример из книги: Эффективная работа с Устаревший код

Чтобы запустить код, содержащий синглтоны в тестовой обвязке, мы должны ослабить свойство singleton. Вот как мы это делаем. Первый шаг - добавить новый статический метод в одноэлементный класс. Метод позволяет заменить статический экземпляр в синглтоне. Мы назовем его setTestingInstance.

public class PermitRepository
{
    private static PermitRepository instance = null;
    private PermitRepository() {}
    public static void setTestingInstance(PermitRepository newInstance)
    {
        instance = newInstance;
    }
    public static PermitRepository getInstance()
    {
        if (instance == null) 
        {
            instance = new PermitRepository();
        }
        return instance;
    }
    public Permit findAssociatedPermit(PermitNotice notice) 
    {
    ...
    }
...
}

Теперь, когда у нас есть этот сеттер, мы можем создать тестовый экземпляр PermitRepository и установить его. Мы хотели бы написать такой код в нашей тестовой среде:

public void setUp() {
PermitRepository repository = new PermitRepository();
...
// add permits to the repository here
...
PermitRepository.setTestingInstance(repository);
}

Вы можете издеваться над интерфейсом ISomeInterface. Затем выполните рефакторинг кода, который его использует, чтобы использовать внедрение зависимостей для получения ссылки на одноэлементный объект. Я много раз сталкивался с этой проблемой в нашем коде, и мне больше всего нравится это решение.

Например:

public class UseTheSingleton
{
    private ISomeInterface myX;

    public UseTheSingleton(ISomeInterface x)
    {
        myX = x;
    }

    public void SomeMethod()
    {
        myX.
    }
}

Потом ...

UseTheSingleton useIt = UseTheSingleton(Example1.Instance);

Ознакомьтесь с инъекцией зависимостей.

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

За советами по модульному тестированию и дальнейшими проблемами тестирования обращайтесь к блогу тестирования Google, в частности к статьям Misko.

Пример

Вы говорите, что пишете тесты, поэтому может быть слишком поздно, но не могли бы вы провести рефакторинг статики для экземпляра? Или есть настоящая причина, по которой указанный класс должен оставаться статическим?

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