Лучшие практики или эффективный подход к написанию интеграционного теста, который запускается в среде непрерывной интеграции
В общем, я пишу интеграционный тест из моего уровня обслуживания / удаленного взаимодействия в базу данных, чтобы я мог проверить, что уровни на стороне сервера интегрированы и протестированы, я хотел бы сохранить откат как ложный, если нет, мы пропустим проверку уровня ограничения базы данных . Это личное предпочтение.
Мы можем использовать разные подходы - Создавать данные для каждого тестового примера и удалять их после выполнения - Запускать с определенным объемом существующих общих данных, таких как (Пользователь)
Могут быть сущности, которые зависят от нескольких других сущностей, и чтобы иметь возможность тестировать такие потоки, требуется много усилий для создания каждой сущности для каждого тестового примера или класса и, возможно, для бизнес-потока, если мы примем решение, мы создадим определенное количество data и выполнить бизнес-поток с определенным количеством тестов и очистить данные. На выполнение таких тестовых случаев может потребоваться много времени.
Существует ли в отрасли эффективный подход или передовая практика для написания интеграционных тестов в средах непрерывной интеграции. Обычно я использую TestNG, поскольку он обеспечивает поддержку пружин. Есть ли фреймворки на основе Java.
Ответы 1
Я думаю, это действительно зависит от проекта, и здесь нет решения серебряной пули.
Как вы утверждаете, действительно существует много подходов, я упомяну несколько:
Воспользуйтесь аннотацией Spring
@Transactionalк тесту. В этом случае пружина будет совершать откат после каждого теста. так что данные, измененные тестом, на самом деле не будут сохранены в базе данных, даже если тест пройден.Не используйте @Transactional, а организуйте тесты так, чтобы они не мешали (каждый тест будет использовать свой собственный набор данных, которые могут сосуществовать с данными других тестов). Если тест не проходит и не «очищает» свои данные, другие тесты все равно должны выполняться. Кроме того, если тесты выполняются параллельно, они все равно не должны мешать.
Используйте новую схему для каждого теста (очевидно, дорого, но все же может быть жизнеспособным вариантом для некоторых проектов).
Теперь вопрос в том, что вы тестируете. Если вы тестируете Java-код, например, что ваши SQL-запросы созданы правильно, то, вероятно, первый способ - это выход.
Конечно, это также зависит от того, какие команды выполняются во время тестов, не во всех базах данных все команды могут быть в транзакции (например, в Postgres вы можете использовать DDL внутри транзакции, в Oracle вы не можете и т. четвертый).
Еще одна проблема, о которой следует подумать во время непрерывного тестирования, - это производительность тестов. Интеграционные тесты выполняются медленно, и если у вас есть монолитное приложение, которое запускает сотни из них, сборка будет очень медленной. Управление сборкой, которая занимает несколько часов, - это большая проблема. Я хотел бы упомянуть здесь 2 идеи, которые могут здесь помочь:
В этом случае очень помогает переход на микросервисы (каждый микросервис выполняет только несколько своих тестов, и, следовательно, сборка каждого микросервиса сама по себе намного быстрее по своей природе)
Еще один интересный вариант, который следует рассмотреть, - это запуск тестов для контейнера докеров базы данных, который запускается прямо в тестовом примере (его также можно кэшировать, чтобы не каждый тест создавал контейнер докеров). Большим преимуществом такого подхода является то, что все работает локально (на сервере сборки), поэтому никакого взаимодействия с удаленной базой данных (производительность) + очистка ресурсов выполняется автоматически, даже если некоторые тесты завершаются неудачно. Контейнер Docker умирает, и все данные, передаваемые tets, очищаются автоматически. Взгляните на проект Тестовые контейнеры, может быть, он вам пригодится
Большое спасибо, TestContainers звучит фантастически