Стоит ли делать Mock для Eloquent в Laravel для юнит-тестов?

Question

[Kenan]

Насколько я знаю, unit-тесты не должны зависеть от внешних сущностей, в том числе работы с БД, и эти сущности обычно заменяют моками/стабами. Но большинство методов и функций в веб-приложении так или иначе с БД работают.

Есть ли смысл подменять работу с БД (писать фальшивый Eloquent и т.д.) в модульных тестах? Нужны ли там вообще модульные тесты, или достаточно писать только функциональные?

Кто как действует в таких ситуациях, кто как пишет тесты?

P.S. Может я конечно не так понимаю смысл unit-тестов. Если нет - то поправьте пожалуйста.

Answer 1

[Вячеслав Плиско]

Тесты должны быть модульными, всё нужно мокать и снимать с них покрытие. Отдельно стоит заводить папку с интеграционными тестами, там мокать не обязательно, но и покрытие снимать нужно отдельно от юнит тестов. Главное не смешивать эти тесты.

Answer 2

[Nimfus]

Юнит тест не должен зависить от БД, этот тест должен проверять логику. Если тест завязан на получении сущности из БД и так далее, то нужно использовать репозитории с интерфейсами соответствующими, а уже то что они возвращают - можно имитировать.

Answer 3

[Александр Аксентьев]

При запуске тестов в laravel накатывается база из миграций: /tests/TestCase.php

Для тестов отдельный .env.test файл с тестовой базой.
Затем с ней идёт работа при необходимости. Заполняется если надо, прогоняются функции.
Artisan::call('migrate....

писать фальшивый Eloquent

Чтобы проверить как работает написанная фальшивая база? А на настоящей всё упадёт в итоге.

Правда база наказывается в начале один раз.

Чтобы исключить влияние тестов друг на друга я каждый тест начинал с очистки и миграции по новой.
Ну это если такая необходимость будет. Думаю в обычном случае такое не надо.

Я не великий тестописец, может это вообще неправильно, но работает :)

Автоматический прогон тестов через travis-ci тоже отлично работает при таком варианте.