Нещодавно я вела TDDing фабричним методом. Метод полягав у створенні або простого предмета, або предмета, загорнутого в декоратор. Оформлений об’єкт може бути одного з декількох типів, що розширює StrategyClass.
У своєму тесті я хотів перевірити, чи клас повернутого об’єкта такий, як очікувалося. Це легко, коли звичайний об'єкт os повернувся, але що робити, коли він загорнутий в декоратор?
Я кодую в PHP, щоб я міг використовувати ext/Reflectionдля пошуку клас загорнутого об'єкта, але мені здалося, що це занадто ускладнює речі, і дещо не відповідає правилам TDD.
Натомість я вирішив ввести, getClassName()що повертає ім'я класу об'єкта, коли його викликають з StrategyClass. Однак, коли його зателефонують від декоратора, він поверне значення, повернене тим самим методом в оформленому об'єкті.
Деякі коди, щоб зробити це більш зрозумілим:
interface StrategyInterface {
public function getClassName();
}
abstract class StrategyClass implements StrategyInterface {
public function getClassName() {
return \get_class($this);
}
}
abstract class StrategyDecorator implements StrategyInterface {
private $decorated;
public function __construct(StrategyClass $decorated) {
$this->decorated = $decorated;
}
public function getClassName() {
return $this->decorated->getClassName();
}
}І тест PHPUnit
/**
* @dataProvider providerForTestGetStrategy
* @param array $arguments
* @param string $expected
*/
public function testGetStrategy($arguments, $expected) {
$this->assertEquals(
__NAMESPACE__.'\\'.$expected,
$this->object->getStrategy($arguments)->getClassName()
)
}
//below there's another test to check if proper decorator is being usedМоя думка тут: чи нормально запроваджувати такі методи, які не мають іншого використання, крім того, щоб спростити одиничні тести? Якось мені це не вірно.