Комментарии 13
Спасибо за пост - сам работаю примерно так же, но за другими топиками не доходили руки расписать этот подход, чтобы новым разработчикам на пальцах не объяснять. Теперь буду ваш пост скидывать:)
Рад, что статья принесёт пользу)
Статья и правда отличная. Не думали для привлечения более массовой аудитории изменить язык текста на английский в Readme и ComponentTests.csproj на GitHub?
Мои коллеги не знают русского и обсудить с ними ваше решение не получится.
Ещё бы весь процесс автоматизировать. Ибо сейчас с этими ChatGPT, контент все пилят просто десятками постов. И в ручную если везде размещать, толком ничего не выйдет...
Я правильно понимаю, что это всё пролетает мимо test coverage?
А что если у сервиса есть парочка своих же микросервисов, как их лучше поднимать (и нужно ли, или мокать)? Инициализировать БД/Кафку для другого сервиса тоже в тестируемом сервисе?
Я их всегда мокаю. В таком случае можно проверить что будет если сервис-зависимость вернёт 500ку или вообще любой нужный ответ.
К тому же у сервиса-зависимости могут быть свои сервисы и так далее. Все локально не поднимешь. Лучше написать простой end2end тест в дополнение, который прямо на тестовом стенде проверит базовые сценарии.
Немного не очевидно, как дебажится вся эта история поднятая где-то в изолированном окружении
В ExtEnvironment опечатка в комменте
/// <summary>
/// Postgres контейнер
/// </summary>
public static RabbitmqContainer RabbitmqContainer { get; set; }
Как писать полезные тесты для микросервисов