Программное обеспечение развивается с течением времени, и автоматизированное тестирование является необходимым условием для непрерывной интеграции и непрерывной доставки. Разработчики пишут различные типы тестов, такие как модульные тесты, интеграционные тесты, тесты производительности и E2E-тесты для измерения различных аспектов программного обеспечения.

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

Но одни только модульные тесты не дают большой уверенности, потому что фактическая сквозная функциональность зависит от интеграции различных внешних сервисов. Таким образом, интеграционные тесты используются для проверки общего поведения системы с использованием реальных зависимостей.

Традиционно интеграционное тестирование представляет собой сложный процесс, который может включать несколько этапов.

Однако, используя Testcontainers, вы можете получить как легкость и простоту модульных тестов, так и надежность интеграционных тестов, работающих с реальными зависимостями.

https://habr.com/ru/post/700286/?utm_source=habrahabr&utm_medium=rss&utm_campaign=700286

В рамках проекта цифровой модернизации для одного из наших клиентов возникла задача миграции данных из одной модели хранения в другую. Для тестирования такого решения мы обратились к BDD практикам и виртуализации зависимостей с помощью контейнеров. В данном посте мы рассмотрим как можно организовать тестирование подобного решения с помощью pytest-bdd и testcontainers на python.

https://habr.com/ru/post/690216/?utm_source=habrahabr&utm_medium=rss&utm_campaign=690216

TestContainers это отличный инструмент, позволяющий тестировать свой код в prod-like окружении.

Однако трудности возникают когда появляется потребность провести сложное интеграционное тестирование используя несколько таких контейнеров, например, базы + очереди, нескольких очередей и т.д.

В этой статье мы разберём как подружить несколько контейнеров, особенно когда один контейнер использует такие настройки, которые генерирует второй контейнер во время своего старта.

Достигнем этого при помощи кастомизации тестового контекста + всеми любимого BeanFactoryBostProcessor'а.

https://habr.com/ru/post/681232/?utm_source=habrahabr&utm_medium=rss&utm_campaign=681232

Каждый из нас знакомился с новомодными библиотеками, фреймворками, инструментами по getting started статьям из документации. В них всё складывается как по полочкам, в пёстрых красках показывается как всё просто и легко. Однако зачастую картина меняется, когда в Ваш новорожденный проект требуется подключить не одну условную библиотеку, а набор. Getting started осложняются появлением инородных элементов, и в процесс приходится подключать инстинкты. Когда за плечами многолетний опыт разработки и не один поднятый с колен проект, такая задача не видится проблемной. Однако, когда Вы делаете это в первый раз, инстинкты подводят. Впоследствии оглядываясь назад, мы жалеем о том, что в начале у нас не было опыта, который есть сейчас. Да и откуда было бы его получить? Ведь в getting started о таком не пишут, а проекты, в которых мы работаем не с самого начала, уже прошли этап становления.

https://habr.com/ru/post/677826/?utm_source=habrahabr&utm_medium=rss&utm_campaign=677826

Несмотря на большую популярность testcontainers в мире java, информации по применению testcontainers в python в интернете практически нет. Даная статья - попытка ликвидировать этот пробел. Если тема показалась интересной, добро пожаловать под кат!

https://habr.com/ru/post/677598/?utm_source=habrahabr&utm_medium=rss&utm_campaign=677598