Как стать автором
Обновить

Комментарии 13

Спасибо за пост - сам работаю примерно так же, но за другими топиками не доходили руки расписать этот подход, чтобы новым разработчикам на пальцах не объяснять. Теперь буду ваш пост скидывать:)

Рад, что статья принесёт пользу)

Статья и правда отличная. Не думали для привлечения более массовой аудитории изменить язык текста на английский в Readme и ComponentTests.csproj на GitHub?

Мои коллеги не знают русского и обсудить с ними ваше решение не получится.

Идея хорошая - нужно будет сделать перевод, заодно английский подтянуть)

Ещё бы весь процесс автоматизировать. Ибо сейчас с этими ChatGPT, контент все пилят просто десятками постов. И в ручную если везде размещать, толком ничего не выйдет...

Я правильно понимаю, что это всё пролетает мимо test coverage?

Да, кажется что coverage можно корректно считать только на юнит тестах.

А что если у сервиса есть парочка своих же микросервисов, как их лучше поднимать (и нужно ли, или мокать)? Инициализировать БД/Кафку для другого сервиса тоже в тестируемом сервисе?

Я их всегда мокаю. В таком случае можно проверить что будет если сервис-зависимость вернёт 500ку или вообще любой нужный ответ.
К тому же у сервиса-зависимости могут быть свои сервисы и так далее. Все локально не поднимешь. Лучше написать простой end2end тест в дополнение, который прямо на тестовом стенде проверит базовые сценарии.

Немного не очевидно, как дебажится вся эта история поднятая где-то в изолированном окружении

Дебажится локально без проблем. Запускаешь тест в дебаге, ставишь брейкпоинт в коде сервиса и он сработает. Никакого remote debug не нужно. Удобный дебаг - это один из главных плюсов этого подхода.

В ExtEnvironment опечатка в комменте
/// <summary>

/// Postgres контейнер

/// </summary>

public static RabbitmqContainer RabbitmqContainer { get; set; }

Спасибо, исправил)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории