Как проверить пакет Laravel, который работает с моделями Eloquent? - PullRequest
Новая
       22

Как проверить пакет Laravel, который работает с моделями Eloquent?

0 голосов
/ 13 сентября 2018

Я создал пакет, который манипулирует красноречивыми моделями, и создал для него тестовые случаи.

В некоторый момент пакет должен вызывать save() или delete() для моделей., который попытался бы поразить базу данных.

Фактический подход к базе данных

В качестве первой попытки Я попробовал этот подход и , также этот .Дело в том, что в контексте пакета (даже с использованием orchestra/testbench) мне нужно настроить базу данных и миграции.Так как сам пакет не имеет никакой модели (но я создал фиктивную модель для целей тестирования), я считаю этот подход излишним.В любом случае, я все же согласился бы настроить подготовленную базу данных sqlite в памяти, которую я тоже пытался, но не мог заставить ее работать (она пыталась использовать forge соединение вместо sqlite, и я не могла заставить его обращаться к другомусоединение. Я могу предоставить подробности о том, что я для этого сделал).

Подход с применением насмешек

Еще одна возможная попытка (в соответствии с моим ограниченным пониманием этого вопроса) заключается в частичной насмешке над моделью.Но после того, как я осмеял его, он не знал, как обрабатывать другие вызовы, такие как fill(), для которых я был готов к общему поведению, но я получил исключение метод не найден.

Подход переопределения метода

Учитывая, что эти две возможные попытки потерпели неудачу, я по умолчанию выбрал третий возможный подход, который сработал для меня, но я, честно говоря, не уверен, так ли это.

Для того, чтобычтобы избежать неудачи теста из-за отсутствия базы данных при вызове методов save() или delete(), я переопределил их ( полный исходный код здесь ): 

class DummyContact extends Model
{
    // ...

    public function save(array $options = [])
    {
        $this->exists = true;
        $this->wasRecentlyCreated = true;
    }

    public function delete()
    {
        $this->exists = false;
        $this->wasRecentlyCreated = false;
    }
}

Таким образом, я 'Я могу протестировать следующий код ( полный источник здесь ): 

public function unifyOnBase()
{
    $mergeModel = $this->merge();

    $this->modelA->fill($mergeModel->toArray());
    $this->modelA->save();
    $this->modelB->delete();

    return $this->modelA;
}

Итак, мой вопрос, является ли этот подход приемлемым?(Я думаю, что это справедливо, я не вижу исключительных ошибок, но я подозреваю, что существуют более элегантные подходы).В случае, если есть предложенные подходы, такие как Mocking или использование реальной БД для выполнения тестов, я хотел бы знать , какие адаптации я должен сделать к моей тестовой базе кода для их взятия.

Последнее, но важное примечание: Я не хочу тестировать модели самостоятельно, я готов протестировать мой код, который использует (и, следовательно, зависит от моделей).

1 Ответ

0 голосов
/ 15 сентября 2018

Благодаря комментарию Йонаса Штауденмейра:

Интеграционный тест с реальной базой данных - самый тщательный способ проверить ваш код. ИМО, у вас должны быть хотя бы интеграционные тесты для основных функций. Вот так Я использую базу данных SQLite для тестирования моего пакета.

Я мог бы создать пару и работать с в памяти sqlite подходом.

  1. Удалены функции переопределения

  2. Добавлен код настройки капсульного теста согласно этого рабочего проекта в качестве примера ( Спасибо за это )

  3. В моем случае мне также потребовалось установить драйвер sqlite sudo apt-get install php7.2-sqlite

Теперь тесты все еще успешно выполняются , в то время как решение выглядит более элегантно и убирает обходные обходные функции, которые легко сломаются при обновлении API Eloquent Models. Это также упростит доступ к тестированию зависимых от отношений функций пакета.

Test pass

...