UPD: Добавил дополнительный тег вопросу, так как под тегом Nest его никто не замечал.
Чем отличается тестирование контроллера и сервиса, если контроллер в любом случае потом выйдет на сервис? (Nest CLI генерирует тесты как для сервисов, так и для контроллеров).
Почему во всех туториалах взаимодействуют с каким-то jest.mockImplementation, если 99,9% сервисов взаимодействуют с базой данных?
Допустим, вместо тестирования написанного кода, который работает с БД, мы будем тестировать фейковые сервисы, потому что это оказалось правильной практикой, но тогда зачем нужен createTestingModule с возможностью импортировать туда реальные контроллеры и провайдеры, если в итоге стучаться мы будем не к ним?
Может быть, вы знаете ещё про какие-то нюансы тестирования NestJS?
Контроллеры - тестим, что отдаются верные статус-коды и дергаются нужные сервисы. Можно проверять ответ, можно проверять валидацию параметров
Сервисы - удобнее тестить когда используется паттерн с репозиторием, а в сервисе зашивается лишь бизнес-логика без обращения к БД.
Просто тестируем бизнес-логику зашитую в сервисе, имплементация репозитория/ORM мокается.
Если говорить о e2e тестах:
Можно использовать supertest. Как и в остальных языках/фреймворках - создается тестовая база, забивается различными необходимыми для теста данными (с помощью фабрик, фикстур). В тестах идет прямое обращение к эндпоинтам и сравнивается результат, будто бы мы тестили это вручную в swagger'е
Простой
