2013-07-29 2 views
0

Для модульного тестирования, как я издеваюсь над зависимостями класса, который использует заводы.Мокальные зависимости класса, использующего статический завод

Например, если у меня есть следующий класс:

public class SignalProcessor 
{ 
    ISignalFilter signalFilter; 

    public SignalProcessor() 
    { 
    this.signalFilter = SignalFilterFactory.GetInstance(); 
    } 
} 

Сейчас в тестовом модуле для SignalProcessor, я хочу, чтобы дразнить из ISignalFilter, т.е. использовать тестовую версию ISignalFilter. Если бы я использовал Dependency Injection вместо Factory, то я мог бы пройти в TestSignalFilter для конструктора SignalProcessor. Но как я могу издеваться над ISignalFilter в заводском случае?

+0

Вы должны рассмотреть возможность использования рамки DI, как замок или Unity (если вы еще не используется). Эти структуры предоставляют возможность экстернализировать фабрики либо XML, либо классу (который сам по себе может быть протестирован по модулю). Тогда у вас может быть только один конструктор «public SignalProcessor (фильтр ISignalFilter)». – aquaraga

ответ

0

Инжектируйте зависимость:

public class SignalProcessor 
{ 
    ISignalFilter signalFilter; 

    public SignalProcessor() : this(SignalFilterFactory.GetInstance()) {} 

    public SignalProcessor(ISignalFilter filter) 
    { 
    this.signalFilter = filter; 
    } 
} 
+0

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

+0

Конечно, много других идей. Это самое лучшее, хотя. Большинство других идей - это вариант «создать государство где-то, а затем использовать его для целей тестирования», что прокладывает путь в ад. – tallseth

+1

Я бы даже избавился от конструктора по умолчанию. Просто предложите версию с параметром ISignalFilter. Тогда класс signalProcessor не имеет зависимости от SignalFilterFactory. Неважно, как создается ISignalFilter - это ответственность вызывающего. – GarethOwen

Смежные вопросы