Как вы тестируете бэкенд на .NET
Вопрос
Расскажите, как вы строите тестирование сервиса на ASP.NET Core и EF Core.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Модульные тесты бизнес-логики без инфраструктуры, моки на границах
Интеграционные тесты через WebApplicationFactory: настоящий конвейер, DI, сериализация
Настоящая база в тестах через Testcontainers вместо InMemory
Изоляция данных между тестами: транзакции, Respawn, уникальные данные
Подмена внешних систем: WireMock или фейковые HttpMessageHandler
Тесты в CI на каждый PR, покрытие как ориентир, а не цель
Что могут спросить следом
- Что вы не тестируете модульно?
- Как сделать интеграционные тесты быстрыми?
Разбор
Основа это модульные тесты на бизнес-логику: доменные правила и сервисы без базы и HTTP. Зависимости на границах (репозитории, внешние API, время через TimeProvider) подменяю моками или фейками. Такие тесты бегут за секунды.
Второй слой интеграционные тесты через WebApplicationFactory<Program>: поднимается настоящий конвейер с DI, middleware, валидацией и сериализацией, а запросы идут через HttpClient. База настоящая, PostgreSQL в контейнере через Testcontainers, потому что InMemory-провайдер не ловит ошибки ограничений и SQL. Миграции применяю один раз на коллекцию тестов, а данные между тестами чищу через Respawn.
Внешние HTTP-сервисы подменяю WireMock или своим HttpMessageHandler через ConfigureTestServices. Всё это идёт в CI на каждый пулреквест. Покрытие смотрю как сигнал о пробелах, но не гонюсь за процентом: важнее, что критичные сценарии, деньги и права доступа, покрыты.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.