Использовать реальные сервисы или моки при тестировании

Что проверяют

Есть ли у вас стратегия тестирования, а не убеждение «только моки» или «только интеграционные». Следом обычно спрашивают, как вы тестируете работу с базой через EF Core и вызовы внешних HTTP-API.

Как отвечать

Ответ начинается с «зависит от уровня теста», и дальше вы это раскрываете:

• юнит-тесты: доменная логика и сервисы, зависимости за интерфейсами подменяются через Moq или NSubstitute. Подменяют то, что медленно или недетерминированно: время (TimeProvider и FakeTimeProvider), внешние API, очереди;
• база данных: настоящая СУБД в контейнере через Testcontainers for .NET, та же, что в проде. Провайдер EF Core InMemory сама Microsoft не советует для тестов: нет транзакций, ограничений и настоящего SQL, поэтому тест зелёный там, где прод падает. Данные между тестами чистит Respawn или транзакция с откатом;
• приложение целиком: WebApplicationFactory<Program> поднимает ASP.NET Core в памяти, а в ConfigureTestServices подменяются только внешние зависимости;
• чужие HTTP-сервисы: заглушка на уровне HTTP через WireMock.Net или свой HttpMessageHandler. Так проверяются сериализация, заголовки, ретраи, ответы 500 и таймауты;
• совместимость с реальным сервисом: контрактные тесты (Pact) или редкий прогон против sandbox провайдера, отдельно от основного CI.

Итог сформулируйте как правило: юнит-тест изолирует логику, интеграционный говорит с настоящей базой в контейнере, внешний мир заменяется HTTP-заглушкой. Если есть свой пример, где мок скрыл баг, который поймал бы тест с реальной базой, расскажите его, это сильнее любой теории.

Где спотыкаются

Мокают DbContext или DbSet. Тогда LINQ выполняется в памяти, и запрос, который EF Core не сможет перевести в SQL, проходит тест и падает в проде.

Проверяют каждый вызов через Verify(..., Times.Once()). Тесты фиксируют реализацию, а не поведение, и ломаются на любом рефакторинге.

Гоняют интеграционные тесты против настоящего стороннего API на каждом прогоне CI. Итог: нестабильные тесты, упор в лимиты запросов и мусорные данные в чужой песочнице.