Документация
Для начала необходимо ознакомиться с документацией по началу работы с Origami Framework
Origami Core
Подключение
Подключается автоматически при подключении Origami Framework.
Аннотации
Чтобы тесты в Test IT и Allure отчетах отображались с указанными шагами, описанием и заголовками необходимо использовать универсальные аннотации (замена Allure и Test IT аннотаций)
Аннотации класса
@Epic, @Feature - стандартные Allure аннотации, в Test IT не используются. @Story - заменяет Allure аннотацию @Story. В Test IT не было аналога, используется в качестве значения пакета для тестовых классов. @DisplayName - заменяет Allure аннотацию @DisplayName. Заменяет Test IT аннотации - @DisplayName, @Title. @Link - заменяет Allure аннотацию @Link. Заменяет Test IT аннотацию - @Link. Для @Link можно выбрать тип ссылки отдельно для Allure(allureType) и отдельно для Test IT(testItType).
Аннотации теста
Тест
@DisplayName - заменяет Allure аннотацию @DisplayName. Заменяет Test IT аннотации - @DisplayName, @Title. @Description - заменяет Allure аннотацию @Description. Заменяет Test IT аннотацию - @Description. @WorkItemIds - стандартная Test IT аннотация, не используется в Allure. Указывается id теста (или id нескольких тестов - @WorkItemIds({"270492", "270493"})), который необходимо пометить как автоматизированный.
Параметризованный тест
Для параметризованного теста так же можно указать @DisplayName - будет влиять только на отображение названия группы тестов в IDE. Значение для теста в Test IT берется из @ParameterizedTest + параметризованные данные.
Шаг
@Step - заменяет Allure аннотацию @Step. Заменяет Test IT аннотации - @Step, @Title.
Аннотации предусловий/постусловий
Ранее в Allure для методов предусловий/постусловий бралось название на англ из метода. Теперь при указании данной аннотации будет взято ее значение.
Добавление описания в Test IT для вложений
В Allure при добавлении аннотации @Attachment к шагу будет добавлено вложение(например: sql запрос, сообщение в очередь и тд.).
Для Test IT реализована аналогичная возможность добавления данных вложений к шагам. Вложения будут добавлены в виде Описания к шагу
при условии, что у шага отсутствует свое описание(@Description).
К методу необходимо добавить аннотацию @Step со значением TEST_IT_ATTACHMENT_TECH_STEP_VALUE. С данным значением
новый шаг не будет создан ни в Allure, ни в Test IT. А описание будет прикреплено к шагу в Test IT, который создавался до вызова данного метода.
Так же необходимо добавить аннотацию @Description, которая будет содержать описание, которое будет прикреплено к шагу.
Task
Позволяет выполнить задачу, которая возвращает результат из отдельного потока. Может вызвать исключение.
Для использования необходимо: 1. Унаследоваться от класса Task 2. Переопределить конструктор с вызовом конструктора родителя
3. Реализовать необходимые для задачи методы - с возвращаемым результатом или без 4. В тестовом методе создать новый объект, где в сигнатуре конструктора:
- первый параметр methodName - название метода для запуска в отдельном потоке
- последующие параметры (могут быть/могут не быть) - входящие параметры для указанного метода
Очередность параметров должна строго соответствовать очередности метода. 5. Вызвать у объекта submit() для запуска задачи в отдельном потоке 6. Вызвать один из нижеперечисленных методов:
- get() / get(long timeout, TimeUnit unit) - при необходимости ожидает завершения задачи, а затем извлекает результат
- cancel(boolean mayInterruptIfRunning) - пытается завершить выполнение текущей задачи
- isCancelled() - возвращает true, если эта задача была отменена до ее завершения
- isDone() - возвращает true, если эта задача завершена
Пример
Реализация класса с методами, которые будут выполняться в отдельных потоках
Использование вышеприведенных методов в шаге теста
Asserts
Asserts включает в себя необходимые проверки для использования в тестах.
Environment
Environment необходим для работы с параметрами. Вычитывает параметры из origami.properties, из /config/{stand}.json, где stand - системное свойство (CI/CD переменная: STAND). Так же вычитывает параметры из statics/routs.json и statics/any.json (необязательные). Существует возможность указать пользовательские файлы конфигураций. Для этого в origami.properties необходимо указать пути до таких файлов. Название параметра должно начинаться с custom.properties.file.path Если какие-либо параметры определены и в пользовательском файле и в файле stand, то возьмется значение из stand файла.
Существует возможность задать глобальный системный параметр для ssl.trust.store. Для этого необходимо в origami.properties указать путь и пароль от сертификата. Возможно указать как полный путь от корня проекта, так и путь конкретно в resources. В примере приведены оба варианта.
Данные параметры можно переопределить в CI/CD - GLOBAL_SSL_TRUST_STORE_LOCATION и GLOBAL_SSL_TRUST_STORE_PASSWORD соответственно.
Существует возможность глобально отключить проверку сертификатов для всех HTTPS-соединений
Данный параметр можно переопределить в CI/CD - DISABLE_SSL_VERIFICATION.
Методы
Получение значения параметра по ключу
Получение значения параметра по ключу или вернется null при отсутствии значения
Получение значения с передачей тестового класса при использовании функциональности параллельности тестов с помощью Origami Framework Test Containers
Параметры из origami.properties будут добавлены в системные параметры.
OrigamiHelper
OrigamiHelper содержит общие вспомогательные методы, такие как ожидания, работа с xml/json, работа с файлами, генерация случайных значений и тд.
Allure
Чтобы задать шаблон URL для ссылок типа issue, необязательно создавать отдельный файл allure.properties и в нем прописывать значение параметра. В origami.properties можно задать аналогичный параметр allure.link.issue.pattern.
Для генерации отчета в один html файл необходимо запустить mvn allure:report. Сгенерированный файл появится по пути /target/site/allure-maven-plugin/index.html
Для генерации excel отчета на основе allure необходимо выполнить команду mvn exec:java@allure-excel. Сгенерированный файл появится по пути /target/allure-report_dd_MM_yyyy.xlsx
CartesianSource
Декартово произведение параметров позволяет прогонять тест с каждой возможной комбинацией входных данных из разных источников. Необходим для проверки поведения на всех сочетаниях различных параметров. Может использовать в качестве списков такие значения как Enum, ints, csv, и прочие.
@CartesianSource
Для использования необходимо на тестовый метод навесить аннотацию @CartesianSource, в которой:
- value - список CartesianValue[]
- exclude - список правил для исключения. Каждое правило — это И-условие с запятыми: "number=2, letter=B" (OR между строками массива). Можно ссылаться по имени оси (CartesianValue.name) или по индексу: "0=2"
- filters - cложные фильтры — класс(ы), реализующие CartesianFilter
@CartesianValue
Множество для проверки на сочетание различных параметров.
- name - имя множества(необязательно)
- displayFormat - "{name}={value}" если name задан, иначе просто "{value}"
- columns - названия значений по порядку. Должно совпадать с количеством значений в списке
- может быть одним из типов:
- enumSource
- ints
- longs
- doubles
- floats
- shorts
- bytes
- chars
- bools
- strings
- csv - строка в виде CSV
- csvDelimiter: по умолчанию ','
- csvQuote: по умолчанию '"'
- csvTrim: по умолчанию 'true'
- field - название поля для использования в перечислении
- method - аналог @MethodSource в Junit. Может принимать как Stream<Arguments>, так и например Stream<String>
@CartesianFilter
Сложные фильтры — класс(ы), реализующие @CartesianFilter. Пример реализации:
Пример использования в тесте
Origami Archetype
Origami Archetype поможет при создании нового проекта из готового шаблона.
Инициализация репозитория
Создаем репозиторий(например, на github), клонируем проект на локальную машину(git clone), создаем необходимую ветку
Создание проекта
В консоли IDE или в консоли ubuntu переходим на уровень выше того каталога, где был инициализирован репозиторий и выполняем команду maven:
Дальнейшие действия
В resources/origami.properties необходимо указать актуальные значения. В pom.xml изменить описание проекта на актуальное. Коммитим и пушим сформировавшиеся файлы.
Ошибки
При возникновении ошибки:
Необходимо проверить /home/{YOUR_PROFILE}/.bashrc (на примере ubuntu) Внутри должна быть строчка
Origami Hibernate
Описание
Модуль для работы с базами данных на основе Hibernate.
Подключение
Необходимо добавить зависимость в pom.xml в проекте:
Так же необходимо создать файл конфигурации для работы с требуемой базой:
- hibernate-postgres.cfg.xml
- hibernate-clickhouse.cfg.xml
- hibernate-oracle.cfg.xml
- hibernate-mssql.cfg.xml
В файле необходимо указать параметр со значением класса драйвера:
Использование
Необходимо унаследовать класс с шагами для работы с конкретной базой данных от CommonFixtureSteps. В конструкторе класса в sessionProperties необходимо указать параметры для подключения и после проинициализировать сессию. Пример:
Пример при использовании функциональности параллельности тестов с помощью Origami Framework Test Containers
Запросы SELECT рекомендуется выполнять на языке hql.
Запросы INSERT, UPDATE, DELETE и тд. рекомендуется выполнять на языке sql.
Динамическая схема
При необходимости использования различных схем, например, в рамках различных стендов, реализована возможность использования динамических схем. Для этого в схеме таблицы необходимо указать схему DYNAMIC_SCHEMA.
В параметрах подключения в таком случае необходимо указать схему
Таким образом запрос будет выполнен с той или иной схемой в зависимости от переданного параметра.
Схема по умолчанию
При выполнении некоторых запросов, в БД может срабатывать триггер, например, при выполнении insert, и будет вызываться функция. Выполнение такой функции может проходить в той схеме, к которой установлено подключение, т.е. без явной привязки к схеме. Для такой ситуации добавлена возможно установки подключения к конкретной схеме БД.
В параметрах подключения необходимо указать схему по умолчанию
Параметры
- hibernate.excel.result.enabled - параметр необходим для прикрепления результата выборки из базы данных в формате Excel. По умолчанию: false. (CI/CD переменная: HIBERNATE_EXCEL_RESULT_ENABLED)
Origami Kafka
Подключение
Необходимо добавить зависимость в pom.xml в проекте:
Таблица совместимости SASL механизмов и Security Protocol
Sasl Mechanism PLAINTEXT SASL_PLAINTEXT SSL SASL_SSL — (нет SASL) ✔ ✗ ✔ ✗ PLAIN ✗ ✔ ✗ ✔ SCRAM-SHA-256 ✗ ✔ ✗ ✔ SCRAM-SHA-512 ✗ ✔ ✗ ✔ GSSAPI (Kerberos) ✗ ✔ ✗ ✔ OAUTHBEARER ✗ ✔ ✗ ✔ EXTERNAL ✗ ✗ ✔ ✔
Properties
- withTestClass() - задает тестовый класс при использовании функциональности параллельности тестов с помощью Origami Framework Test Containers
- setBootstrapServers() - список адресов Kafka-брокеров
- setGroupId() - имя группы консьюмеров, которые работают вместе
- addSecurityProtocol() - протокол безопасности для подключения клиента. Опционально с указанием regexp для названия стенда. При запуске тестов на стендах, для которых указан протокол, будет использован данный протокол, для запусков на остальных стендов будет использован протокол без указания regexp.
- addSaslMechanism() - определяет, какой механизм аутентификации SASL (Simple Authentication and Security Layer) будет использоваться клиентом Kafka
- setUsername() - имя пользователя для аутентификации
- setPassword() - пароль пользователя для аутентификации
- setClientId() - идентификатор приложения (client), зарегистрированного во внешней системе авторизации (например, OAuth-сервере)
- setClientSecret() - секретный ключ (пароль), привязанный к этому clientId
- setSaslOauthBearerTokenEndpoint() - URL-адрес, по которому Kafka-клиент будет запрашивать OAuth 2.0 access token у внешнего сервера авторизации, указывая свои clientId, clientSecret. Этот токен затем используется для аутентификации с Kafka-брокером
- setSaslOauthBearerJwksEndpoint() - URL, по которому Kafka-брокер (или клиент) получает открытые ключи для проверки подписи JWT-токенов
- setSslTruststoreLocation() - путь к truststore-файлу, в котором хранятся сертификаты доверенных центров сертификации (CA certificates)
- setSslTruststorePassword() - пароль для доступа к truststore-файлу
- setSaslKerberosServiceName() - определяет имя Kerberos-сервиса, под которым зарегистрирован Kafka-брокер в Kerberos KDC (Key Distribution Center)
- setSslKeystoreLocation() - путь к файлу keystore (обычно формата JKS или PKCS12), в котором хранятся приватный ключ и сертификат клиента (или брокера)
- setSslKeystorePassword() - пароль для доступа ко всему keystore-файлу (для его открытия)
- setSslKeyPassword() - пароль, который защищает приватный ключ внутри keystore
- setTopicPrefix() - префикс будет добавлен перед названием топика кафки. Необходим для обхода различий в названии топиков на разных стендах.
- setTopicPostfix() - постфикс будет добавлен после названия топика кафки. Необходим для обхода различий в названии топиков на разных стендах
- setRetryWaitingTime() - установка общего времени ожидания для попыток чтения
- setRetryMaxAttempts() - установка попыток чтения
- setRetryReadTimeout() - установка времени ожидания между попытками чтения
Producer
Использование
Необходимо унаследоваться от ProducerSteps с указанием в конструкторе параметров для подключения. Пример:
Пример при использовании функциональности параллельности тестов с помощью Origami Framework Test Containers:
Методы
Метод для задания партиции для отправки
Отправка сообщения в топик
Отправка объекта в топик в формате JSON
Consumer
Использование
Необходимо унаследоваться от Consumer с указанием в конструкторе параметров для подключения. Пример:
Пример при использовании функциональности параллельности тестов с помощью Origami Framework Test Containers:
Методы
В результате выполнения методов вернется объект KafkaRecord, который будет содержать ключ, само сообщение, временную метку сообщения, заголовки и тд.
Метод для задания глубины временного интервала вычитки сообщения для методов, начинающихся с readFirst... и readAll...
Методы для задания партиции или списка партиций
Получение сообщения/й из топика по слову/ам поиска. Поиск будет произведен как по телу сообщения, так и по ключу сообщения. При отсутствии слова поиска(null) любое сообщение будет считаться подходящим.
Аналогичные методы с возможностью получения пустого результата(при отсутствии сообщений не будет выброшена ошибка).
Аналогичные методы с маппингом сообщения из XML/JSON.
Аналогичные методы с вычиткой из compact топика
Метод для подписки на топик с возможностью отписаться в нужный момент(unsubscribeAndGetResults, unsubscribeWhenGetMessage)
Аналогичный метод подписки, но с получением найденного по слову поиска сообщения в формате XML/JSON(Class clazz)
Методы для отписки от топика кафки с возможностью получения пустого списка результатов. Вернется список строк
Аналогичные методы для отписки от топика кафки, но с получением сообщений в формате XML/JSON
Методы для отписки от топика кафки при получении сообщения или списка сообщений по заданному слову поиска. При неполучении сообщения в течении 2 сек или заданного интервала тест будет провален.
Аналогичные приведенным выше методы, но с возможностью получения пустого результата (не найдено сообщение в топике).
Topic
Представляет собой Enum, который содержит названия топиков.
Использование
Необходимо реализовать Topic. Пример:
TestDataKafka
Используется для прочтения текстовых файлов(txt, xml, json, etc) с возможностью дальнейшего редактирования/использования в тестах. TestDataKafka
Использование
Необходимо добавить property: "kafka.test.data.package", которое содержит путь до пакета с текстовыми файлами.
Пример использование в тесте:
Файл "doc-list-add-rq.xml" будет вычитан из директории, которая указана в системных параметрах. После можно получить содержимое файла в тесте из объекта TestDataKafka:
Параметры
- fail.on.unparsed.kafka.records - при значение false в случае ошибки парсинга такие записи будут пропущены и выведены в лог после отписки от топика. Иначе, если значение не задано или равно true, при ошибке парсинга тестовый сценарий будет провален
- kafka.test.data.package - путь до пакета с файлами для TestDataKafka. По умолчанию: src/main/resources/test_data/kafka.
Origami RestAssured
Описание
Модуль для работы с HTTP-запросами на основе RestAssured.
Подключение
Необходимо добавить зависимость в pom.xml в проекте:
Использование
Необходимо унаследовать класс CommonSteps от RestSteps. Необходимо использовать метод получения базового RequestSpecBuilder: getRequestSpecBuilder(). В CommonSteps реализуются методы "сборщики" базовых RequestSpecBuilder. Пример:
Пример при использовании функциональности параллельности тестов с помощью Origami Framework Test Containers:
Далее необходимо унаследоваться от CommonSteps. Унаследованный класс должен содержать методы для работы с конкретным сервисом, который содержит методы получения RequestSpec для методов сервиса. Пример:
Далее необходимо унаследоваться от класса с общими шагами сервиса. Унаследованный класс будет содержать методы, доступные в тесте (методы, выполняющие get, post, put..., методы с проверками).
Методы
RestSteps содержит методы, для проверки статус кодов ответов. Примеры: Статус код 200:
Статус код 404:
Статус код 500:
Метод then(), доступный в классе с шагами проверок. Возвращает последний response для дальнейшей работы с ним.
Так же реализованы методы расширяющие стандартные у RestAssured, которые позволяют добавлять только not null значения в заголовки, параметры и тд.
Метод withSkipFields(String... fieldsToSkip): необходим для исключения переданных полей (fieldsToSkip) из процесса сериализации/десериализации JSON-данных при выполнении запросов.
Origami WebSocket
Подключение
Необходимо добавить зависимость в pom.xml в проекте:
WsSteps
Использование
Необходимо унаследоваться от WsSteps с указанием в конструкторе параметров для подключения. Параметр withWss: true при https, иначе false. Пример:
Пример при использовании функциональности параллельности тестов с помощью Origami Framework Test Containers:
Методы
Осуществление подписки на топик
Осуществление подписки на топик с маппингом результата на переданный класс
Осуществление отписки от топика и получение результата. В случае переданного класса вернется список из объектов переданного класса. В ином случае вернется List<String>
Методы для отписки от топика при получении сообщения или списка сообщений. При неполучении сообщения в течении 2 сек или заданного интервала тест будет провален.
Аналогичные приведенным выше методы, но с возможностью получения пустого результата (не найдено сообщение в топике)
Осуществление отписки от топика без получения результата.
WsTopic
Представляет собой Enum, который содержит названия топиков.
Использование
Необходимо унаследоваться от WsTopic. Пример:
Origami Selenide
Описание
Модуль для работы с Web UI на основе Selenide.
Подключение
Необходимо добавить зависимость в pom.xml в проекте:
Параметры
- web.site.url - базовый URL-адрес
- web.browser.name - браузер для использования. По умолчанию: chrome (CI/CD переменная: WEB_BROWSER_NAME)
- web.timeout - таймаут в миллисекундах для провала теста, если условия все еще не выполнены. По умолчанию: 5000
- web.page.load.timeout - таймаут загрузки веб-страницы (в миллисекундах). По умолчанию: 10000
- web.browser.yandex.binary - путь до бинарника яндекс браузера в случае его использования
Origami IBM MQ
Подключение
Необходимо добавить зависимость в pom.xml в проекте:
Producer
Использование
Необходимо унаследоваться от IbmMqProducer с указанием в конструкторе параметров для подключения. Пример:
Методы
Отправка сообщения в топик
Browser
Использование
Необходимо унаследоваться от IbmMqBrowser с указанием в конструкторе параметров для подключения. Пример:
Методы
В результате выполнения метода вернется Message. Сообщение останется доступно для чтения из очереди.
Consumer
Использование
Необходимо унаследоваться от IbmMqConsumer с указанием в конструкторе параметров для подключения. Пример:
Методы
В результате выполнения метода вернется первый Message в очереди и сообщение будет более недоступно в очереди.
MessageHelper
MessageHelper содержит вспомогательные методы для работы с Message.
Методы
В результате выполнения метода из переданного Message будет извлечено сообщение и возвращена String.
Origami Test Containers
Подключение
Необходимо добавить зависимость в pom.xml в проекте:
Использование
Необходимо унаследовать класс c реализацией контейнеров(например, Containers) от TestContainers. В конструкторе Containers необходимо реализовать контейнеры, которые будут запущены перед стартом тестов, и добавить их в список контейнеров containers. Для включения поднятия контейнеров перед стартом тестов, необходимо выставить test.containers.enabled = true или для CI/CD переменную TEST_CONTAINERS_ENABLED = true.
Для создания преднастроенных контейнеров можно использовать методы:
- withPostgres() - собирает контейнер Postgres с настройками по умолчанию
- Образ: postgres:16
- Имя: testdb
- Фиксированный порт: 5432
- Пользователь: postgres
- Пароль: postgres
- withOracle() - собирает контейнер Oracle с настройками по умолчанию
- Образ: gvenzl/oracle-xe:21-slim
- Имя: testdb
- Фиксированный порт: 1521
- Пользователь: test
- Пароль: test
- withMSSQL() - собирает контейнер MS SQL с настройками по умолчанию
- Образ: mcr.microsoft.com/mssql/server:2019-CU18-ubuntu-20.04
- Имя: master
- Фиксированный порт: 1433
- Пользователь: sa
- Пароль: A_Str0ng_Required_Password
- withClickhouse() - собирает контейнер ClickHouse с настройками по умолчанию
- Образ: clickhouse/clickhouse-server:23.8-alpine
- Имя: default
- Фиксированный порт: 8123
- Пользователь: test
- Пароль: test
- withKafka() - собирает контейнер Kafka с настройками по умолчанию
- Образ: apache/kafka:3.9.1
- Фиксированный порт: 9092
- Пользователь: ""
- Пароль: ""
- withIbmMq() - собирает контейнер IBM MQ с настройками по умолчанию
- Образ: icr.io/ibm-messaging/mq:9.3.0.0-r1
- Фиксированный порт: 1414
- Queue manager: QM1
- Channel: DEV.APP.SVRCONN
- Пользователь: app
- Пароль: passw0rd
- buildDefaultAppContainer(String imageName, String imageVersion, String containerName, Integer startPriority, String javaDockerImageName, String ciJavaOpts) - собирает контейнер с сервисом
- imageName - имя docker образа
- imageVersion - версия docker образа
- containerName - имя контейнера
- startPriority - приоритет запуска контейнера (начиная от 1 - самый приоритетный и запустится первым, может быть null(низший приоритет))
- javaDockerImageName - название образа Java для сборки сервиса (по умолчанию: eclipse-temurin:17-jre)
- ciJavaOpts - параметры для виртуальной машины Java (JVM) при запуске через CI/CD
Пример:
Имя containerName будет использоваться для установки значений переменных стенда(например в test_containers.json)
- kafka:
- containerName (по умолчанию kafka_container)
- containerName + "_bootstrap_servers"
- databases:
- containerName (по умолчанию postgres_container, oracle_container, mssql_container, clickhouse_container в зависимости от бд)
- containerName + "_host"
- containerName + "_port"
- containerName + "_name"
- containerName + "_username"
- containerName + "_password"
- services:
- containerName + "_host"
- containerName + "_port"
- containerName + "_ws_host"
- containerName + "_ws_port"
- ibm mq:
- containerName (по умолчанию ibm_mq_container)
- containerName + "_host"
- containerName + "_port"
- containerName + "_queue_manager"
- containerName + "_username"
- containerName + "_password"
Пример использования данных динамических значений в /config/test_containers.json
Для создания топиков Kafka необходимо в список kafkaTopics добавить топики с помощью метода getTopic(String name, int partitions, short rf, boolean compact). Топики будут созданы при старте контейнера с Kafka.
При создании контейнера с kafka автоматически поднимется контейнер с kafka ui (http://localhost:9091).
Для выполнения миграций базы данных(последовательного выполнения sql скриптов) необходимо вызвать метод setDatabaseScriptLocations(List<String> databaseScriptLocations) для конкретной базы данных.
Сами скрипты необходимо разместить в resources например в пакете db.migrations. Будут выполнены все скрипты в указанном пакете. Можно указывать несколько пакетов. Как в примере выше, в случае с пакетом db.migrations в setDatabaseScriptLocations необходимо будет передать db/migrations. Файлы со скриптами должны быть версионированы и начинаться с v1__name.
Для создания очередей IBM MQ необходимо в список ibmMqQueues добавить названия очередей. Очереди будут созданы при старте контейнера с IBM MQ.
Для поднятия контейнеров на фиксированных портах можно использовать метод withFixedPorts()
- kafka: 9092
- postgres: 5432
- oracle: 1521
- ms sql: 1433
- clickhouse: 8123
- services: 8080 (и далее в порядке возрастания)
- ibm mq: 1414
Без использования метода контейнеры будут подниматься на случайном порту(например, 41287).
При реализации нескольких классов наследников TestContainers необходимо точно понимать в рамках какого класса требуется поднимать контейнеры. Для этого существует аннотация @TestContainerName, в которой можно задать имя, и затем при формировании mvn команды указать это имя с помощью параметра test.containers.name. Так же можно ограничить пакет для поиска классов с помощью параметра test.containers.pkg.prefix. Пример команды maven:
Пример класса реализующего TestContainers:
Стоит обратить внимание на блок с ограничением RAM и CPU (withCreateContainerCmdModifier()). Если не задать ограничения, то контейнер может забирать все доступные ресурсы хоста. При указании ограничений нагрузка становится контролируемой.
Параллельность
Реализован уникальный механизм параллельного выполнения тестовых сценариев с поднятием необходимого количества тестовых окружений в зависимости от количества потоков.
Часто бывает так, что из-за особенностей системы и требований к ней не представляется возможным выполнение тестовых сценариев параллельно в несколько потоков с использованием стандартного функционала JUnit. Например, наличие единой настройки влияющей на состояние системы, единой сущности и тп. Выходом из данной ситуации может стать запуск тестовых сценариев на различных тестовых окружениях. Но тут же возникает ряд проблем: например нужно менять docker compose и прописывать несколько конфигураций сервисов, в тестах нужно менять конфигурацию для запуска на различных инстансках сервиса, в самих тестах нужно выбирать какие тесты и на каком окружении будут выполняться и тд. А что если мы захотим добавить еще одно тестовое окружение? Это все требует не малых временных затрат и несет сопутствующие трудности и проблемы.
В Origami Framework реализован уникальный механизм решения данной проблемы, который включает взаимодействие со стандартной реализацией параллельности JUnit 5. При старте тестового класса определенный поток будет закреплен за данным тестовым классом. Чтобы включить параллельный запуск JUnit 5 необходимо в pom.xml добавить параметры
Данные параметры будут переданы в JUnit 5 в одноименные параметры для параллельного выполнения тестовых сценариев. Дополнительных настроек JUnit производить не требуется.
- junit.jupiter.execution.parallel.enabled - необходимо выставить в true для параллельного запуска
- junit.jupiter.execution.parallel.config.fixed.parallelism - количество потоков при параллельном запуске
Для включения создания тестовых окружений для каждого потока необходимо в origami.properties добавить
Больше не требуется выполнять никаких дополнительных действий и менять код. Количество тестовых сред будет автоматически меняться при изменении количества потоков. Поднимется нужное количество инстансов сервисов. К названиям топиков kafka при создании автоматически добавится "_thread_{номер потока}" и автоматически изменится содержание переменных топиков у сервиса. Аналогично будет работать для базы данных Postgres, к названию схемы добавится "_thread_{номер потока}" и автоматически заменится в переменной сервиса. Для явного задания названия переменной со схемой Postgres у TestContainer можно использовать метод setPostgreSQLSchemaProperty(). Аналогичные методы можно использовать для других БД. Важное уточнение для расширений JUnit 5, таких как BeforeAllCallback. Определенный поток закрепляется за тестовым классом, но при создании классов с шагами и других классов в самом расширении отсутствует автоматическая информация о запущенном тестовом классе, поэтому тестовый класс необходимо явно передать. Он содержится в ExtensionContext context. Ниже приведен пример полной реализации расширения и используемого класса с шагами на примере БД
В расширении в beforeAll методе тестовый класс получаем с помощью вызова context.getRequiredTestClass(). В классе для работы с БД добавляем конструктор, который на вход принимает Class> testClass. При создании конфигурации БД добавляем вызов .withTestClass(testClass) и при получении конфигов из Environment добавляем в вызов тестовый класс Environment.get("db.host", testClass). Таким образом во всех местах, где необходимо создавать объект DbFixtureSteps, код остается без изменений. Необходимо только дополнить расширение передаваемым тестовым классом и отредактировать создание конфигурации. Схожие изменения при необходимости требуется проделать и для классов работы с kafka, api и тд.
CI/CD
При запуске в CI/CD возможно переопределить переменную REPOSITORIES_DIR, которая указывает на директорию куда будет склонирован код сервиса. По умолчанию: repositories. Пример реализации в .gitlab-ci.yml с возможностью клонирования ветки сервиса. REPO_1_DIR должна называться так же, как образ сервиса в коде.
Параметры
- test.containers.enabled - старт контейнеров при запуске тестов (CI/CD переменная: TEST_CONTAINERS_ENABLED)
- test.containers.app.log.level - уровень логирования контейнеров с сервисами созданных из преднастроенных методов. По умолчанию: INFO (CI/CD переменная: TEST_CONTAINERS_APP_LOG_LEVEL)
- test.containers.name - имя в аннотации @TestContainerName у класса с реализацией контейнеров (CI/CD переменная: TEST_CONTAINERS_NAME)
- test.containers.pkg.prefix - имя пакета для поиска классов с реализацией контейнеров (CI/CD переменная: TEST_CONTAINERS_PKG_PREFIX)
- test.containers.fixed.ports - поднятие контейнеров на фиксированных портах. Переопределяет метод withFixedPorts() (CI/CD переменная: TEST_CONTAINERS_FIXED_PORTS)
- test.containers.execution.parallel - включает автоматическое создание тестовых сред согласно количество параллельных потоков при включении параллельности JUnit (CI/CD переменная: TEST_CONTAINERS_EXECUTION_PARALLEL)