Комментарии 6
1) Короткое создание моков + удаление их в tearDown.
2) Парсинг докблока.
Могу ошибаться, но разве это не сложный велосипед? Для быстрого создания моков есть codeception/stub, а для парсинга докблока — phpDocumentor/ReflectionDocBlock (Но возможно не совсем подходит, конкретно под ваш кейс)
Показывая короткий и красивый код в самом тесте, вы, как мне кажется, не учитываете код, который придется писать в докблоке.
Беру теоретичсекий код, который должен работать, и все это заменить:
protected $mocks = [ ];
protected createMock($className, $constructorParams = [] ){
//тут код создания мока
$this->mocks[] = $mock;
return $mock;
}
protected function tearDown()
{
$this->mocks = null;
parent::tearDown();
}Разве нет?
Спасибо за указание интересных библиотек.
Сначала отвечу на вопрос по поводу чистого кода теста и чистых phpDoc блоков. Да, вы правильно отметили, что механическое задание объектов для мокирования все равно должно присутствовать в том или ином виде. В нашем случае при указании объектов для мокирования тест получался настолько большим — из-за большего числа зависимостей в старом коде, который необходимо покрывать тестами, — что вариант с раздутыми аннотациями вкупе с возможностями IDE оказался предпочтительней.
В вашем предложении функцию createMock надо явно вызывать и явно указывать ее className, а также явно держать поле для нее: это следствие того, что у нас соглашение не использовать магические ассоциативные массивы, например, из-за плохого хинтинга. Тем не менее, соглашусь, что с случае хорошо написанных классов, которые тестируются, предложенный вариант, возможно, не является оптимальным.
$var = $this->createMock(Class::class);
@property Namespace\SubSpace\Class var
$this->var;а также явно держать поле для нее: это следствие того, что у нас соглашение не использовать магические ассоциативные массивы, например, из-за плохого хинтинга.
Да, вы используете класс propertyBag, в котором у вас хранится тот же массив. Не нравится массив? Используйте коллекцию. Да и тайпхинтинга у вас тоже нет. Ведь все создается динамически.
Еще раз повторюсь, ничего не имею против, классная статья, интересная идея и архитектура. Я для себя даже кое что подчерпнул. Но на мой взгляд — излишнее усложнение того, что можно сделать проще. Просто профита не вижу, от написанной сложности.
Еще раз спасибо за фидбек.
У нас в IDE (PhpStorm) Intelli Sens полноценно работает по такому phpDoc: подтягивает типы, подсказывает, как можно мокать по объекту PHPUnit_Framework_MockObject_MockObject, подсказывает, что входит в изначальную сигнатуру объекта. Именно поэтому (полноценно работающий Intelli Sens) такой вариант оказался очень удобным для нас.
Извиняюсь, что не указал это в исходной статье.
Эта статья о том, как я решил проблему отказа от написания не несущего ценности кодаНепонятно как вы определяете ценность кода. Если речь идет про Boilerplate_code, то даже у него есть своя ценность. Иначе его бы не писали.
По теме, чем аннотации лучше абстрактных классов, трейтов, хелперов?
Автономизация Unit-тестов в PHPUnit