Какие внешние зависимости мокались через тестовые контейнеры
Что проверяют
Есть ли у вас реальный опыт интеграционных тестов и понимаете ли вы, что Testcontainers ничего не мокает: он поднимает настоящую зависимость в Docker. Следом спрашивают, почему не обошлись in-memory базой и как тесты не мешают друг другу.
Как отвечать
Вопрос про ваш опыт, поэтому каркас стройте на своём проекте, со своими зависимостями и цифрами. Начните с поправки в терминах: моки живут в юнит-тестах (Moq, NSubstitute), а контейнеры дают настоящий сервис для интеграционных. Дальше перечислите, что поднимали:
- базу данных:
Testcontainers.PostgreSqlилиTestcontainers.MsSql. Миграции EF Core накатываются на контейнер перед прогоном, строку подключения даётGetConnectionString(); - кеш и брокеры: модули для Redis, RabbitMQ, Kafka;
- облачные сервисы: MinIO или LocalStack вместо S3, Azurite вместо Azure Storage;
- сторонние HTTP API: WireMock.Net в контейнере или в процессе. Вот это действительно заглушка, потому что платёжный шлюз в тест не поднимешь.
Покажите, как это склеено. Контейнер стартует один раз на класс или коллекцию тестов через IAsyncLifetime и IClassFixture в xUnit, WebApplicationFactory<Program> подменяет строку подключения в приложении, а данные между тестами чистятся библиотекой Respawn или откатом транзакции. Итог назовите честной цифрой: сколько идёт прогон в CI и какие баги поймали, которые юнит-тесты пропускали.
Если опыта не было, так и скажите и опишите, как бы сделали: что подняли бы в контейнере, что закрыли бы WireMock.Net и почему.
Где спотыкаются
Говорят «замокали базу через Testcontainers». Путаница терминов сразу выдаёт, что человек пересказывает чужой опыт.
Заменяют базу провайдером EF Core InMemory. Он не знает транзакций, ограничений и особенностей SQL, тесты проходят там, где прод падает, и документация EF Core прямо не советует его для таких тестов.
Поднимают новый контейнер на каждый тест и не чистят данные. Прогон растягивается на десятки минут, а тесты начинают зависеть от порядка.