Использование связки HSQLDB+DBUnit для Unit-тестирования Java-кода, работающего с базами данных

[pyatigil]

да это все прекрасно работает на пару с ОРМ, более того при некоторой фантазии можно сделать немного симпатичнее — я для себя скрещивал DbUnit с хибернейтом и yaml процессором чтобы получить возможность писать тесты наподобие этого: pastebin.com/q9xRV29g — DbUnitRule строка в начале это все, что мне нужно, чтобы данные из ямл файла о пользователе попали в БД и можно было проверить можно ли залогиниться этим самым пользователем. Сам ямл файл выглядит так: pastebin.com/3n8fJtBC — это позволяет дбюниту через хибернейтовский коннекшн впаять данные во все 4 таблицы

[cleam]

Обычно, крупные проекты так или иначе завязаны на какие vendor-specific фичи БД. Так что маловероятно, что это заработает на практике

[redcraft]

Согласен, под vendor-specific фичи такой подход не применим. Но под vendor-specific зачастую и пишут фасад на vendor-API и получают информацию подключаясь к фасаду, а не напрямую к СУБД. Здесь классические mock'и все решают.

[sergei-grigorev]

Примеры, наподобие Hello World, как правило совершенно не подходят для Production. Приведите реальные примеры, которые могут использоваться для крупных модульных проектов. Пока что ничего лучше интеграционного тестирования нам найти не удалось, хотя очень хочется.

[malexejev]

Сергей, а почему хочется? Интересно какой у вас юзкейс.

Обычно, если команда уже отжалась на полноценный CI стенд с работающими автотестами, VCS хуками и нотификацией, привыкла к нему и тд, то назад возвращаться никому не охота. Появляется ведь возможность сделать автоматизированные перфоманс тесты, стресс тесты, HA и т.д., начинаются мысли о внедрении continuous delivery. Да и вобще удовольствие от работы как-то растет.

[sergei-grigorev]

Мы сейчас работаем над сравнительно новым продуктом, и пока что приходиться тестироваться с помощью интеграционных тестов, которые проходят всю цепочку, начиная от клиентского фасада — серверный фасад — получение результата. Ради этого приходиться запускать веб-сервер, деплоить на него наши приложения, и только потом запускать тесты, используя клиентские фасады, которые обращаются к веб-серверу. Это не слишком долго, но хотелось бы, чтобы тест можно было запускать и видет результат его работы куда быстрее. Сейчас в серверном фасаде основные проблемы — работа с EJB моделями, а также с отдельными JDBC запросами. Ищу способ, как тестировать только серверный фасад, без необходимости каждый раз деплоить все на локальный сервер, но на рабочей (тестовой) базе данных.

[redcraft]

Спасибо, я посмотрю на H2 Database. Но мне кажется, что большой разницы не будет. Тестирование кода с помощью HSQLDB+DBUnit подходит лишь для небольших разработок — на них движок базы для тестов не будет играть большого значения

[MzMz]

HQSQL не поддерживает ни блокировок на уровне строк (что важно для обеспечения конкурентного доступа к данным), ни каких-либо фич присущих «взрослым» бд — так что ценность такого тестирования весьма сомнительна.

[malexejev]

Ругать не работать, конечно, но. Черт возьми, я не мог пройти мимо.
1) HSQLDB — откуда взяли это старье? Выше правильно написали про H2, это уже давно рекомендуемый вариант для in-memory java dbms, в частности для тестов.
2) Код и конфиги в таком виде, как в статье, нигде не используются. Подавляющее большинство юзает Spring или другой IoC, и датасорсы/конфиги подтягиваются через него. У нас ведь не только «тесты» и «не тесты». Как правило образуется набор окружений — dev, qa, staging, prod, etc. Это давным давно обкатано, используется и выглядит ясно и лаконично. См. static.springsource.org/spring/docs/3.0.0.M4/spring-framework-reference/html/ch12s08.html
3) Создание схемы в яве — без комментариев. Заполнение словарных таблиц референсными данными наверное тоже там…

Ладно, перестаю ругаться. Мой совет — Максим, отправьте это обратно в черновики и посмотрите как сейчас организуется тестинг с embedded базами в яве. Можно начать со ссылки выше.

[redcraft]

По поводу кода, методов и фитч разобранных в статье — это лишь общий вариант. Безусловно сейчас не пишут SQL внутри JAVA-классов, но у меня и цель была не показать как писать database oriented приложения, я лишь показал возможную связку HSQLDB+DBUnit.
За ссылку спасибо.