Лучшие практики или эффективный подход к написанию интеграционного теста, который выполняется в среде непрерывной интеграции

Question

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

Мы можем следовать различным подходам - Создать данные для каждого теста и удалить их после выполнения - Выполнить с определенным количеством существующих общих данных, таких как (Пользователь)

Могут существовать сущности, зависящие от нескольких других сущностей, и чтобы иметь возможность тестировать такие потоки, требуется много усилий для создания каждой сущности для каждого тестового случая или класса и, возможно, для бизнес-потока, если мы принимаем решение, то создаем определенный объем данных и выполнить бизнес-поток с определенным количеством тестов и очистить данные. Эти вещи могут занять много времени для запуска таких тестовых случаев.

Существует ли в отрасли эффективный подход или передовой опыт для написания интеграционного теста в средах непрерывной интеграции. Я обычно использую TestNG, поскольку он обеспечивает поддержку пружины. Существуют ли какие-либо основанные на Java фреймворки.

Answer 1

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

Есть действительно много подходов, как вы утверждаете, я упомяну несколько:

1. Воспользуйтесь аннотацией Spring @Transactional на тесте. В этом случае пружина выполнит откат после каждого теста. поэтому данные, измененные тестом, не будут сохранены в базе данных, даже если тест пройден.

2. Не используйте @Transactional, но организуйте тесты так, чтобы они не мешали (каждый тест будет использовать свой собственный набор данных, которые могут сосуществовать с другими данными тестов). Если тест не пройден и не «очищает» свои данные, другие тесты все равно должны выполняться. Кроме того, если тесты выполняются параллельно, они все равно не должны мешать работе.

3. Использовать новую схему для каждого теста (очевидно, дорого, но все же может быть приемлемым вариантом для некоторых проектов).

Теперь реальный вопрос в том, что вы тестируете. Если вы тестируете Java-код, например, если ваши SQL-запросы созданы правильно, то, вероятно, первый путь - это путь.

Конечно, это также зависит от того, какие команды выполняются во время тестов, не во всех базах данных все команды могут быть в транзакции (например, в Postgres вы можете использовать DDL внутри транзакции, в Oracle вы не можете и т. д.).

Другая проблема, о которой следует задуматься во время непрерывного тестирования, - это производительность тестов. Интеграционные тесты медленные, и если у вас есть монолитное приложение, которое запускает сотни из них, то сборка будет очень медленной. Управлять сборкой, которая работает часами - большая боль. Я хотел бы упомянуть здесь 2 идеи, которые могут помочь здесь:

• В этом случае очень помогает переход на микросервисы (каждый микросервис выполняет только несколько своих тестов и, следовательно, сборка каждого микросервиса сама по себе намного быстрее)

• Еще один интересный вариант, который следует учитывать, - запуск тестов для док-контейнера базы данных, который запускается прямо в тестовом примере (его также можно кэшировать, чтобы не каждый тест вызывал док-контейнер). Большим преимуществом такого подхода является то, что все выполняется локально (на сервере сборки), поэтому никакое взаимодействие с удаленной базой данных (производительность) + очистка ресурсов не выполняется автоматически, даже если некоторые тесты не пройдены. Контейнер Docker умирает, и все данные, помещенные tets, очищаются автоматически. Взгляните на проект Testcontainers , может быть, вы найдете его полезным