классы модульного тестирования, которые используют конкретные классы, объявленные в теле кода

Question

Очень просто то, что я пытаюсь выяснить, есть ли способ чисто модульного тестирования этой части кода? Я могу создать его экземпляр и выполнить некоторые утверждения, но я имею в виду фактическое модульное тестирование, где я бы высмеивал объект службы, чтобы удалить все зависимости тестируемого класса, и фактически он проверял бы только этот класс, а не его зависимые службы (в данном случае ConcreteService).

public class Foo{

    public SomeResult DoSomething(){
        var service = new ConcreteService();
        var foo = service.Execute();
        return foo;
    }

}

Мой обычный подход состоит в том, чтобы не создавать объекты такого типа в моем теле кода, но с учетом сценария, в котором это нельзя изменить, каковы мои варианты его модульного тестирования?

Answer 1

Учитывая ограничение (что вы не можете изменить / перекомпилировать этот код ), я боюсь, что вы мало что можете сделать, кроме как "интеграционное тестирование", - реальные зависимости, медленные тесты.

Создание зависимости внутри метода вместо принятия ее в качестве аргумента ctor или метода усложняет задачу.

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

Answer 2

Я знаю, что вы упомянули, что это будет пример ситуации, которую вы не можете изменить, но я буду бороться за реорганизацию класса так, чтобы ConcreteService мог быть внедрен как зависимость.Рефакторинг - это гораздо более простой подход к решению проблемы плохого дизайна.Из того, что вы написали, я не вижу причин, по которым вы не смогли бы сделать это.

РЕДАКТИРОВАТЬ: FWIW, я согласен с @Gishu.Если вы абсолютно не можете изменить класс, например, у вас его нет и у вас нет возможности его изменить, тогда интеграционные тесты - лучший способ сделать это.Однако, если вы видите код и то, что он делает, я придерживаюсь того, что я сказал ранее в том, что на самом деле нет причин, по которым вы не должны проводить рефакторинг.

Answer 3

Если service.Execute () является виртуальным, то большинство фальшивых сред поддерживают это.Я лично использую Rhino.Mocks .

См. этот вопрос , в котором подробно описываются возможности использования платформ Mocking на неинтерфейсах и рассматриваются возможности платформ Mocking для перехвата виртуальных вызовов.

Если это не виртуальный, и вы не можете изменить его, тогда вы можете использовать Родинок .Вышеупомянутый пост также упоминает о возможности использовать TypeMock, который я лично не использовал.

Описание Moles на сайте исследований Microsoft:

Moles - это облегченная платформадля тестовых заглушек и обходных путей в .NET, основанном на делегатах.Кроты могут использоваться для обхода любого метода .NET, включая не виртуальные / статические методы в закрытых типах.