Если ваши интеграционные тесты тонут в хаосе тестовых данных, а ручные SQL-скрипты вызывают головную боль, то Database Rider — ваш супергерой. В прошлом посте мы разобрали основы, а сегодня нырнем в практику: от многоформатных датасетов и хитрых проверок БД до ускорения тестов и организации данных без бардака.
Работа с наборами данных
Database Rider не ограничивается только одним форматом. Есть возможность выбрать один из поддерживаемых форматов данных:
- YAML — читаемый и лаконичный формат. Рекомендуется разработчиком.
- XML — более многословный, но еще поддерживаемый формат, в основном используется, когда нужна обратная совместимость с DBUnit.
- JSON — также как и YAML простой текстовый формат. Отличный выбор, если данные генерируются системами, работающими с API.
- CSV — простой табличный формат, очень полезен, особенно если выгружаете снимок данных из БД различными графическими редакторами типа dbeaver.
- XLS или XLSX — наиболее распространенный формат. Ваш выбор, когда в процессе проверки или подготовки данных участвуют люди, не связанные с программированием.
Проверка состояния после теста
Database Rider дает возможность проверить состояние БД после выполнения теста с помощью аннотации @ExpectedDataSet. Вы описываете ожидаемое состояние БД после выполнения теста в файле и задаете его в параметрах аннотации.
Rider автоматически сравнит состояние БД с ожиданием после теста. Если данные не совпадают, то тест упадет с понятной ошибкой.
Стратегии очистки БД
Перед каждым тестом Rider может очищать и наполнять таблицы БД. Для этого есть несколько стратегий:
- INSERT - вставляет данные в таблицу (по умолчанию);
- CLEAN_INSERT — старые данные удаляются и вставляются новые;
- TRUNCATE_INSERT — данные удаляются с использованием TRUNCATE;
- REFRESH — обновляются существующие данные, которые есть в dataset, и вставляются новые, остальные данные не обновляются;
- UPDATE - обновляются существующие столбцы, если есть строки, которых нет в dataset, то выбрасывается исключение.
В зависимости от контекста можно выбрать ту или иную стратегию. Если часто используете CLEAN_INSERT, то для ускорения тестов лучше использовать TRUNCATE_INSERT. Помимо стратегий существуют параметры cleanAfter и cleanBefore, которые также очищают таблицы до и после запуска теста.
Интеграция с JUnit 5
Database Rider, в отличие от DBUnit, создан для работы с современным стеком. Его интеграция с Spring и JUnit 5 интуитивна и понятна. В контексте @SpringBootTest всё работает "из коробки". Database Rider автоматически находит Datasource в контексте Spring и использует его для подключения к БД. Никакая дополнительная конфигурация не нужна.
Версионирование данных
С ростом числа тестов растет и число датасетов, чтобы поддержать порядок, применяйте следующие практики:
- Структурируйте датасеты, разделите их по модулям, функциональности и слоям.
- Вынесите общие данные (например, справочники) и включайте там, где они нужны. Аннотация @DataSet позволяет загружать несколько датасетов.
- Используйте простые и понятные имена файлов, которые отражают назначение набора данных и/или состояние БД до и после теста.
- Избегайте создания одного гигантского all-data.yml. Маленькие, сфокусированные наборы данных легче читать, поддерживать и переиспользовать.
Заключение
Database Rider превращает управление тестовыми данными в простой и удобный процесс:
- Есть возможность настраивать сложные сценарии с минимальными усилиями.
- Проверять изменения состояния БД.
- Значительно ускорять создание и заполнение тестовых наборов.
- Позволяет поддерживать порядок в большом количестве тестовых данных.
Особенно эффективно использовать Database Rider с Spring Boot и Testcontainers!
Примеры кода есть в моем telegram-канале
#Database #DevOps #Java #DatabaseRider