Unit Test Параметрический Abstract Factory

Рассмотрим следующую конструкцию:Unit Test Параметрический Abstract Factory

public class PhoneAbstractFactory 
{ 
     public IPhoneFactory GetPhoneFactory(string type, bool needSmartPhone) 
     { 
      if (type == "Samsung") 
       return new SamsungFactory(needSmartPhone); 

      if (type == "Apple") 
       return new AppleFactory(needSmartPhone); 

      else throw new Exception("Unknown phone type: " + type); 
     } 
} 

    public interface IPhoneFactory { } 

    public class SamsungFactory : IPhoneFactory 
    { 
     public SamsungFactory(bool needSmartPhone) 
     { 
     } 
    } 

    public class AppleFactory : IPhoneFactory 
    { 
     public AppleFactory(bool needSmartPhone) 
     { 
     } 
    }

Как я могу проверить только PhoneAbstactFactory? Если я хочу проверить его, неизбежно должен быть экземпляр экземпляра AppleFactory или SamsungFactory; это означает, что если тест должен быть принят, необходимо, чтобы построение обеих заводов всегда считалось истинным. В противном случае тестовая область охватывает две фабрики, что не очень хорошо.

источник

2015-09-03 Hans

В чем проблема с возвратом фактического экземпляра? конечно, ваш тест хочет в основном проверить, что, когда строка «Samsung» возвращает «IPhoneFactory», является экземпляром «SamsungFactory»? Как еще вы собираетесь его протестировать? –

@SamHolder Проблема заключается в том, что таким образом проверяется не только «PhoneAbstractFactory», но и «SamsungFactory». Это не ** unit ** test – Hans

@Hans, imho, это не совсем так, вы, конечно же, проверяете, что завод получает вам правильный тип объекта. Таким образом, неявно этот объект будет создан, но он не проверяет логику фабрики, вы можете делать абсурдные вещи в конструкторе, тест пройдет, пока не будет никакого исключения. –

Я думаю, что вы слишком догматичны по поводу определения модульного теста.

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

тест устройства не обязательно протестировать один класс, но в unit of functionality or behavior (не authour книг связаны не говорят, он проверяет один класс, но один логическую концепции, которая:

может охватить один метод, целый класс или несколько классов, работающих вместе для достижения единой логической цели, которая может быть проверена.

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

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

источник

2015-09-04 05:58:28

Убежденный. Спасибо за пролить свет – Hans

К сожалению, этого уточнения нет в книге; поэтому результат, дополненный автором на его веб-сайте – Hans

Unit Test Параметрический Abstract Factory

ответ

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