Модульное тестирование модели FuelPHP

Итак, у меня есть очень простая (по крайней мере, сейчас) модель, которая возвращает контакт через идентификатор первичного ключа:

class Model_Contact extends \Fuel\Core\Model
{
    public function get_by_id($contact_id)
    {
        return Entity_Contact::find_by_pk($contact_id);
    }
}

Класс Entity_Contact выглядит следующим образом (нерелевантное содержимое массива опущено):

class Entity_Contact extends \Core\Entity_Base
{
    protected static $_table_name = 'contacts';
    protected static $_properties = array(...);
    protected static $_public_settable_properties = array(...);
    protected static $_rules = array(...);
}

Примечание: \Core\Entity_Base расширяет \Fuel\Core\Model_Crud

Я мог бы использовать это в контроллере так:

$model = new Model_Contact();
$contact = $model->get_by_id(4);

Я знаю, что для модульного тестирования я должен смоделировать фактический вызов базы данных (Entity_Contact::find_by_pk), но я не уверен, как это сделать. Поскольку я использую функциональность Fuel Model_crud (где средства доступа к БД на самом деле являются частью объектной модели предметной области), я не уверен, что смогу полностью имитировать базу данных — или, может быть, я что-то упускаю.

Итак, вопрос: как бы вы написали тест для Model_Contact::get_by_id()?

Заранее спасибо!


unit-testing php fuelphp activerecord
person Jesse Bunch    schedule 17.10.2012    source источник
comment
Я не использовал Fuel, но он кажется более процедурным, чем ООП, со статическими вызовами повсюду, используя классы как наборы функций [1]. Чтобы что-то можно было протестировать, оно должно быть написано с явными зависимостями, чтобы вы могли внедрять настоящие объекты или поддельные (моки или заглушки). Вам следует взглянуть на другие фреймворки, такие как Symfony2, где все легко тестируется, потому что он основан на этом принципе. [1]: github.com/fuel/core/ blob/1.4/develop/classes/model/crud.php (проверьте метод find. Он вызывает \DB::select() и т. д.)   -  person ChocoDeveloper    schedule 20.10.2012
comment
Вы правы, и когда я копался в этом, я обнаружил, что это не очень поддается проверке. На самом деле, MVC, каким мы его знаем сегодня, с тем, что проповедуется в документации различных фреймворков, полностью игнорирует тестируемость.   -  person Jesse Bunch    schedule 22.10.2012
comment
Позвольте мне настаивать =p, Symfony2 и Silex реализовали все таким образом, чтобы его можно было проверить. Вам ничего не навязывают, вам даже не нужно расширяться от контроллера, если вы этого не хотите (мы делаем это только для удобства). И объекты Entity — это обычные старые объекты php, без базовой модели для расширения, потому что мы используем шаблон Data Mapper. С другой стороны, может быть немного сложно начать работу (по сравнению с другими фреймворками), но это потому, что нужно многое знать о веб-разработке, а Symfony2 охватывает большинство ее аспектов, всегда используя лучшие практики.   -  person ChocoDeveloper    schedule 23.10.2012

Ответы (2)


arrow_upward
0
arrow_downward

В вашем тесте может потребоваться создать объекты, чтобы вы могли протестировать свои методы.

  1. Создайте объекты, которые будут сохранены в базе данных.
  2. Проверить get_by_id
  3. Удалить созданный объект

Это не самая великолепная вещь в мире, но она могла бы проверить ваш метод... а?

person iturgeon    schedule 29.11.2012
comment
Да, поскольку я не могу издеваться над фактическим объектом доступа к базе данных, это мой единственный вариант. Ба вздор. - person Jesse Bunch; 29.11.2012

arrow_upward
1
arrow_downward

Вы можете легко издеваться над ним, если используете AspectMock. https://github.com/Codeception/AspectMock

person kenjis    schedule 09.02.2015