Comments 11
Вариант 4
Используем в сервисе интерфейс нужного для нашего домена репозитория
Репозитории не создаём в конструкторе, а внедряем снаружи.
Тогда все прекрасно тестируется: делается упрощённая реализация репы и работа идёт с ней в вашем сервисе.
Согласен, вариант хорош. Но как тогда проверить, сохранилась ли сущность в БД? Или сохранение тоже вынесено в репозиторий?
Если юнит-делать. Например так: В репозитории сделать метод add(). В оригинальной репе флаш будет, в имитации — просто добавление в приватный массив. Тогда ваш сервис будет тестить я без зависимостей и легко.
Или так: мокать репу, и мокать ее методы, а сохранение тестировать уже в интеграционном тесте, как сказали ниже.
Правда в вашем случае может вообще отпасть его надобность, а слову суффикс Service сам на это намекает, что логику бы определить по конкретнее.
Тесты как уже написали выше, бывают разными, и ничего не мешает иметь несколько видов тестов сразу.
Но проверка, вызывался ли в сервисе метод сохранения данных — это же не интеграционное тестирование? Или в юнит-тестах нет необходимости проверять этот момент?
Да, я не правильно выразился в высказывании
Но как тогда проверить, сохранилась ли сущность в БД
Конечно же, речь шла о проверке вызова метода сохранения.
В проектах на Symfony, как правило, репозитории используют только для выборки данных, а сохранение осуществляется через EM. Именно такой кейс и рассмотрен в статье
Делаем изоляцию с использованием транзакций у себя в интеграционных тесах.
Можно конфигурировать изоляцию на уровне каждого теста или на уровне тестсьюта.
Может что-то интересное почерпнете:
https://github.com/oroinc/platform/blob/16f80bfdbcc2edd513b853cbd64307bd13eaab22/src/Oro/Bundle/TestFrameworkBundle/Test/WebTestCase.php#L217
PHPUnit. Мокаем Doctrine Entity Manager