Ответы пользователя по тегу Yii
  • Не могу понять для чего нужны Entities в ООП PHP, Yii?

    @thyratr0n
    Есть разные подходы к пониманию смысла этих вещей.
    Entities чаще всего используются в контексте DDD-подхода. Там это означает то, что объект может изменять свое состояние (фигура может менять цвет, стакан может заполняться и тд). Супротив Entities выступают т.н. ValueObject, которые используются только для чтения и менять свое состояние не могут.
    И те, и другие используются в бизнес-логике приложения и генерируются либо хранилищами (storage), либо сервисам (в зависимости от выбранного подхода).

    В контексте же Yii понятие Entity не применяется. ибо там структурной единицей бизнес-логики выступают экземпляры ActiveRecord чаще всего (сам фреймворк к этому располагает), либо, иногда, наследники Model.

    Главное - это то, что сущность не обязательна должна сохраняться as is, т.е. иметь четкую проекцию в БД, ибо сущностью может выступать экземпляр паттерна Композит - все зависит от хранилища/сервиса, который это дело будет "CRUD'ить".
    Ответ написан
  • Как правильно писать unit тесты?

    @thyratr0n
    Непонятно, что вы хотели получить в ответ, ибо не задали четкого вопроса.

    Во-первых, вы, конечно, "удачно" выбрали Yii первой версии в качестве примера. Эта фреймворка не очень приспособлена для изготовления "тестопригодного" кода, ибо содержит на всех стадиях функционирования большое количество "магии". Не верите? Попробуйте что-то наваять на базе CActiveRecord и запилить юнит-тесты. У вас получится что угодно, но не то, что надо.
    Самый главный аспект юнит-тестирования состоит в том, что один тест (метод класса-теста) должен решать строго одну задачу, а не проверять в фоне целую подсистему.
    На одном из своих проектов я решил эту проблему, написав целую свору заглушек.
    Во-вторых, все зависит от задач. Грубо говоря, юнит-тесты проверяют код как есть. Следующий уровень тестов (не берусь его называть, ибо я их постоянно путаю) проверяет бизнес-сценарии. И самый высокий уровень проверяет все это дело в связке с внешними интерфейсами.
    И в-третьих, один тест не должен включать код других тестов, ибо каждый тест должен быть изолирован, считая, что весь остальной код работает. Именно поэтому, когда вы пишете, например, тест для мелкой модельки, не нужно гонять работу с БД: считается, что вся подсистема взаимодействия с БД _работает_.

    Да, и еще. Очень часто путают моки и стабы.
    Стаб - это заглушка - код, который "глушит" выполнения другого. Цель заглушки - проверка того, _что_ возвращает объект в своей работе. В вашем случае нужен какой-то объект, который не позволит коду выполняться далее LoginForm::login(). Как это сделать? При статической типизации кода - никак. Нужна надстройка, которая будет динамически использовать данные объекты, чтобы их можно было заменить на стабы.
    Мок - это надстройка над тестируемым объектом, целью которой является проверка того, _как_ работает объект внутри, именно поэтому моки всегда строятся на Reflection.
    Ответ написан