TDD и заводской шаблон

Question

Я новичок в tdd. Я пытаюсь реализовать приложение, которое считывает конфигурацию из файла и выполняет некоторые действия.

У меня есть интерфейс конф элемент:

interface ConfElement{ 
    doSamething() 
} 

то у меня есть два ConcreteConfElement, который реализует ConfElement:

ConcreteConfElementA:

class ConcreteConfElementA implements ConfElement{ 
    private propA; 

    doSamething() 
} 

ConcreteConfElementB:

class ConcreteConfElementB implements ConfElement{ 

    private propB; 

    doSamething() 
} 

, то у меня есть завод, который создает ConcreteConfElementA и ConcreteConfElementB прочитанный от Configuration объект передан на заводе;

ConfElementFactory(){ 
    public ConfElementFactory(Configuration conf) 

    ConfElement createConf(){ 
    if(conf.hasElA){ 
     return new ConcreteConfElementA(); 
    } 
    else{ 
     return new ConcreteConfElementB(); 
    } 
    } 
} 

Как я могу проверить заводской метод? Он хорошо разработан для tdd?

Answer 1

Должно быть относительно легко проверить условную логику вашего завода. Два испытания могут быть:

1. инстанцировать Configuration объект с hasEla, чтобы быть правдой. Произведите активацию фабрики элементов с помощью теста Configuration и подтвердите, что экземпляр ConcreteConfElementA был возвращен.

2. Повторите шаг 1, но установите hasEla в false и утвердите, что возвращается ElementB.

---

Я считаю, что именно этот завод является проверяемым, поскольку она позволяет вызывающему абоненту вводить Configuration.

Answer 2

С TDD вам нужно сначала написать тесты перед производственным кодом. TDD рекомендует шаблоны проектирования появляться сверхурочно, а не сразу.

• Написать тест для случая использования 1
• Реализовать достаточно коды, чтобы пройти этот тест (без интерфейсов!)
• Test Передает
• Написать тест для случая использования 2
• Реализовать достаточно коду пройти этот тест
• тест пройден
• Refactor удалить дубликат (подсказка: паттерн Factory выходит!)

Таким образом, код проверен на 100%, и нет необходимости беспокоиться о том, что шаблон можно проверить или нет. Рефакторинг является ключевым элементом TDD.