Как стать автором
Обновить

Комментарии 13

отличная статья, спасибо!
Когда-то пробовал DB-unit.
Из воспоминаний — желание иметь возможность исходные данные хранить не в виде XML, а в виде файла с командами SQL.
Да, насколько я знаю, такой возможности нет.
Но XML-формат предоставляет всё-таки небольшую абстракцию над базой данных. В этом и преимущество DBUnit. Интеграционные тесты и так достаточно чувствительны, стоит ли привязывать их к SQL-синтаксису конкретной БД.
Почему бы там была привязка? Входной .sql-файл можно очевидным образом разбить на отдельные запросы и дальше эти инструкции через jdbc выполнить по-очереди. И это будет работать на всех dbms, более-менее поддерживающих стандартный sql.
Разные БД — разные диалекты, разные типы данных в маппингах. Из моего опыта, даже на простейших типах данных (boolean, например) уже начинаются проблемы несовместимости скриптов. Что уж говорить о каких-нибудь LOB'ах.
Какой маппинг? Какие диалекты? Тупой raw SQL statement execution на конкретном диалекте конкретной dbms.
Почему бы там была привязка? [...] будет работать на всех dbms, более-менее поддерживающих стандартный sql

Тупой raw SQL statement execution на конкретном диалекте конкретной dbms.

Обнаружены взаимоисключающие параграфы. Так всё-таки, стандартный SQL, или конкретный диалект конкретной DBMS?
У Вас детектор сломался. Поддержка более-менее стандартного SQL означает, что символ ';' используется для разделения инструкций и никак иначе.
Хорошо. В таком случае, возвращаясь к вопросу, «почему бы там была привязка» — отвечаю, что привязка теста к конкретной БД будет заключаться именно в «конкретном диалекте конкретной DBMS», который заключается отнюдь не только в способе разделения инструкций.
Привязка конкретного теста — да. Привязка реализующей библиотеки — нет.
Интеграционные тесты и так достаточно чувствительны, стоит ли привязывать их к SQL-синтаксису конкретной БД.

Я вообще-то и говорил про привязку конкретных тестов.
Предлагаю закончить этот демагогический тред.
У нас тесты прокручиваются на hsqldb в памяти (настраивается отдельный юнит) вся схема БД генерится из юнита в @Before
По сути, у меня всё точно так же. Тег jdbc:embedded-database по умолчанию поднимает HSQLDB. Юнит для краткости кода настраивается прямо в entityManagerFactory, и его точно так же можно инъектировать с помощью @PersistenceUnit. Единственное отличие — в моём случае схема пересоздаётся автоматически за счёт присутствия аннотации @DirtiesContext.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории