Организация функциональных и модульных тестов в Laravel

Научился писать тесты, но теперь иногда кажется что некоторые из них излишни. Например, я обернул POST запрос отправки сообщения в функциональные тесты, где проверил все-все случаи входных данных, проверив и работу в целом, и работу валидатора. Вот контроллер:

public function dialogSend(SendMessageRequest $request, WriteMessageRepository $repository)
{
    $repository->createMessage($request->input('to'), $request->input('message'));

    return back()->with('ok', 'sended');
}

Простейший метод, дёргает репозиторий который создает сообщение (при этом в самом репозитории нет абсолютно никаких проверок, т.е. он доверяет тем, кто его вызывает). Все проверки уже были сделаны в Request классе. С функциональным тестов всё ОК, но возникает вопрос по UNIT тестам - есть ли какой-то смысл опять тестировать данный метод репозитория? Разница будет лишь в том что путь теста короче - без контроллера, а напрямую. Но в репозитории нет никаких проверок, как я и говорил, получается там нечего тестить? Где найти эту грань? По сути весь проект это CRUD, где все контроллеры дёргуют репозитории, либо сервисы которые по сути являются просто контейнерами для вызовов репозиториев, ну и с какой-нибудь небольшой логикой и преобразованиями. Хотя я видел статью где тестируют и миддлвары, и контроллеры, и сервисы, и репозитории по отдельности. Подытожу, что именно надо на самом деле тестировать модульными тестами, а что для чего достаточно функциональных? Пожалуйста, в контексте Laravel, и в контексте примерной архитектуры как у меня: контроллеры либо вызывают репозитории, либо сервисы, которые в свою очередь делают тоже самое только в большем масштабе. Вообще, мне кажется, что стоит проводить только функциональные тесты со всеми видами входных данных.


Ответы (0 шт):