Как ускорить CI/CD пайплайны?
TLDR; шардим тесты, параллелим, для изоляции используем пул БД и чистим через db template. github
Это довольно частый вопрос, который я слышал во всех компаниях где я работал.
Поднятие рядом с раннерами NuGet proxy (кэш) за счет локализации ускоряет билды, но в конечном счете, самым дорогим шагом остается запуск тестов.
Если рассматривать пирамиду тестирования, то согласно ему, основным объёмом должны быть юнит тесты, далее интеграционные и e2e.
Здесь логика довольно простая - юниты легко пишутся и понимаются. Дают неплохой буст к уверенности что та или иная функция работает корректно и при этом обычно прекрасно параллелятся и в итоге даже тысячи тестов выполняются в сумме < 1 сек.
Но юниты чаще применимы в библиотечном коде, на агрегаты, ValueObjects и прочие мелкие функции. Например конвертеры, мапперы, шифровальщики. Такие тесты хороши, но их часто недостаточно.
Интеграционные тесты в свою очередь бывают очень разными. Это может быть проверка работы двух и более функций, классов или вызов API сервиса в изоляции от остального мира.
Стандартный способ написать интеграционный тест для AspNetCore это WebApplicationFactory. А если у сервиса есть база данных, то слой хранения данных либо мокают, используют InMemory providers или более легковесные СУБД, типа SqlLite в InMemory режиме. Чем это плохо, думаю, объяснять не нужно, поэтому всё чаще используется подход с TestContainers для поднятия реальной СУБД с которым сервис работает на проде. Так мы повышаем доверие к тестам, но тесты становятся значительно дольше.
Почему это всё еще интеграционный тест, а не E2E?
- Запускается не отдельный реальный процесс как на проде, а TestServer, который эмулирует HTTP вызовы.
- Тестируется только один сервис с замоканными ответами от внешних сервисов.
- В документации Microsoft тоже написано, что это интеграционный тест и коммьюнити с этим согласно.
Какие у них плюсы?
- Тестируется весь HTTP пайплайн (мидлвари, роутинг, сериализация, аутентификация и т.п.)
- Тестируется всё приложение: API (controllers), Infrastructure (db), Application (usecases), Domain (aggregates, domain events).
- Используется реальная база данных хоть она и поднята в контейнере.
- Приближено к реальному использованию сервиса, а значит обеспечивает высокий уровень доверия.
- Можно зафиксировать сразу и контракты API и исходящие события, если речь идет об event-driven architecture.
E2E в свою очередь тестируется от лица пользователя, причём вся система работает вместе. Но обычно ограничиваются базовыми сценариями из-за их дороговизны и хрупкости. Но некоторые кейсы можно покрыть только такими тестами, поэтому они ценны.
Несмотря на то что в пирамиде тестирования должно быть больше юнитов, на моей практике основной костяк составляют именно интеграционные тесты из-за широкого охвата и пользы которую она несёт.
Но такие тесты уже не дешевые и легко сломать изоляцию, сделать их нестабильными.
Они выполняются сильно дольше. База данных поднимается перед всеми тестами и чистится содержимое перед каждым тест кейсом. Так же ради изоляции приходится запускать новый инстанс WebApplication на каждый тест кейс, что тоже дается не бесплатно.
Ускорить тесты помогает следование практикам:
- К тестам относимся как к бизнес коду т.е. пишем качественно, продумываем архитектуру, особенно для arrange части теста.
- Грамотно организуем работу с шаренными ресурсами.
- Тесты максимально изолированы и параллелятся.
- Периодическое профилирование, поиск узких мест
- Сбор метрик скорости работы тестов (jUnit, Reporting, own metrics)
продолжение поста в комментариях
TLDR; шардим тесты, параллелим, для изоляции используем пул БД и чистим через db template. github
Это довольно частый вопрос, который я слышал во всех компаниях где я работал.
Поднятие рядом с раннерами NuGet proxy (кэш) за счет локализации ускоряет билды, но в конечном счете, самым дорогим шагом остается запуск тестов.
Если рассматривать пирамиду тестирования, то согласно ему, основным объёмом должны быть юнит тесты, далее интеграционные и e2e.
Здесь логика довольно простая - юниты легко пишутся и понимаются. Дают неплохой буст к уверенности что та или иная функция работает корректно и при этом обычно прекрасно параллелятся и в итоге даже тысячи тестов выполняются в сумме < 1 сек.
Но юниты чаще применимы в библиотечном коде, на агрегаты, ValueObjects и прочие мелкие функции. Например конвертеры, мапперы, шифровальщики. Такие тесты хороши, но их часто недостаточно.
Интеграционные тесты в свою очередь бывают очень разными. Это может быть проверка работы двух и более функций, классов или вызов API сервиса в изоляции от остального мира.
Стандартный способ написать интеграционный тест для AspNetCore это WebApplicationFactory. А если у сервиса есть база данных, то слой хранения данных либо мокают, используют InMemory providers или более легковесные СУБД, типа SqlLite в InMemory режиме. Чем это плохо, думаю, объяснять не нужно, поэтому всё чаще используется подход с TestContainers для поднятия реальной СУБД с которым сервис работает на проде. Так мы повышаем доверие к тестам, но тесты становятся значительно дольше.
Почему это всё еще интеграционный тест, а не E2E?
- Запускается не отдельный реальный процесс как на проде, а TestServer, который эмулирует HTTP вызовы.
- Тестируется только один сервис с замоканными ответами от внешних сервисов.
- В документации Microsoft тоже написано, что это интеграционный тест и коммьюнити с этим согласно.
Какие у них плюсы?
- Тестируется весь HTTP пайплайн (мидлвари, роутинг, сериализация, аутентификация и т.п.)
- Тестируется всё приложение: API (controllers), Infrastructure (db), Application (usecases), Domain (aggregates, domain events).
- Используется реальная база данных хоть она и поднята в контейнере.
- Приближено к реальному использованию сервиса, а значит обеспечивает высокий уровень доверия.
- Можно зафиксировать сразу и контракты API и исходящие события, если речь идет об event-driven architecture.
E2E в свою очередь тестируется от лица пользователя, причём вся система работает вместе. Но обычно ограничиваются базовыми сценариями из-за их дороговизны и хрупкости. Но некоторые кейсы можно покрыть только такими тестами, поэтому они ценны.
Несмотря на то что в пирамиде тестирования должно быть больше юнитов, на моей практике основной костяк составляют именно интеграционные тесты из-за широкого охвата и пользы которую она несёт.
Но такие тесты уже не дешевые и легко сломать изоляцию, сделать их нестабильными.
Они выполняются сильно дольше. База данных поднимается перед всеми тестами и чистится содержимое перед каждым тест кейсом. Так же ради изоляции приходится запускать новый инстанс WebApplication на каждый тест кейс, что тоже дается не бесплатно.
Ускорить тесты помогает следование практикам:
- К тестам относимся как к бизнес коду т.е. пишем качественно, продумываем архитектуру, особенно для arrange части теста.
- Грамотно организуем работу с шаренными ресурсами.
- Тесты максимально изолированы и параллелятся.
- Периодическое профилирование, поиск узких мест
- Сбор метрик скорости работы тестов (jUnit, Reporting, own metrics)
продолжение поста в комментариях