Интеграция DBUnit и Spring TestContext Framework

[michaelarshinov]

отличная статья, спасибо!

[Dair_Targ]

Когда-то пробовал DB-unit.
Из воспоминаний — желание иметь возможность исходные данные хранить не в виде XML, а в виде файла с командами SQL.

[forketyfork]

Да, насколько я знаю, такой возможности нет.
Но XML-формат предоставляет всё-таки небольшую абстракцию над базой данных. В этом и преимущество DBUnit. Интеграционные тесты и так достаточно чувствительны, стоит ли привязывать их к SQL-синтаксису конкретной БД.

[Dair_Targ]

Почему бы там была привязка? Входной .sql-файл можно очевидным образом разбить на отдельные запросы и дальше эти инструкции через jdbc выполнить по-очереди. И это будет работать на всех dbms, более-менее поддерживающих стандартный sql.

[forketyfork]

Разные БД — разные диалекты, разные типы данных в маппингах. Из моего опыта, даже на простейших типах данных (boolean, например) уже начинаются проблемы несовместимости скриптов. Что уж говорить о каких-нибудь LOB'ах.

[Dair_Targ]

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

[forketyfork]

Почему бы там была привязка? [...] будет работать на всех dbms, более-менее поддерживающих стандартный sql

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

Обнаружены взаимоисключающие параграфы. Так всё-таки, стандартный SQL, или конкретный диалект конкретной DBMS?

[Dair_Targ]

У Вас детектор сломался. Поддержка более-менее стандартного SQL означает, что символ ';' используется для разделения инструкций и никак иначе.

[forketyfork]

Хорошо. В таком случае, возвращаясь к вопросу, «почему бы там была привязка» — отвечаю, что привязка теста к конкретной БД будет заключаться именно в «конкретном диалекте конкретной DBMS», который заключается отнюдь не только в способе разделения инструкций.

[Dair_Targ]

Привязка конкретного теста — да. Привязка реализующей библиотеки — нет.

[forketyfork]

Интеграционные тесты и так достаточно чувствительны, стоит ли привязывать их к SQL-синтаксису конкретной БД.

Я вообще-то и говорил про привязку конкретных тестов.
Предлагаю закончить этот демагогический тред.

[Akvel]

У нас тесты прокручиваются на hsqldb в памяти (настраивается отдельный юнит) вся схема БД генерится из юнита в @Before

[forketyfork]

По сути, у меня всё точно так же. Тег jdbc:embedded-database по умолчанию поднимает HSQLDB. Юнит для краткости кода настраивается прямо в entityManagerFactory, и его точно так же можно инъектировать с помощью @PersistenceUnit. Единственное отличие — в моём случае схема пересоздаётся автоматически за счёт присутствия аннотации @DirtiesContext.